[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] dietlibc port to ppc64el


On 04/06/2016 11:45 PM, Breno Leitao wrote:
> On 04/06/2016 04:57 PM, Christian Seiler wrote:
>>> Do you know this problem? Is it related to something like:
>>> https://github.com/ensc/dietlibc/blob/87a59f2e6dc11d9f5b82c9d6eff09aae2daa1bbb/ppc64/setjmp.S#L3-L7
>> I believe I have fixed that recently independently of your report (not
>> tested though), just do a git pull and try again, see the other email
>> I just sent.
> I just got it and installed on my system and tried to build mksh correctly this
> time.
> During the build, mksh is generated incorrectly, which causes:
>   Got a binary, doing run-time checks.
>   debian/meat: 124: debian/meat: ./mksh: not found
> mksh is, in fact, generated but using a non existent loader, as:
>   $  file builddir/full/mksh
>     builddir/full/mksh: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked,  interpreter /usr/lib/ld.so.1, BuildID[sha1]=42a8a40ef508fc73c56e67abd4e0c4029748f39f, not stripped

This is weird, because it appears that you built the full variant of mksh
with dietlibc, which is _not_ supposed to happen, the full variant is always
supposed to be built against glibc. How did you try to build mksh?

Note that the full mksh variant is dynamically linked. dietlibc has some
code for dynamic linking, but at least the Debian package doesn't currently
support that for a variety of reasons (on any platform, not even x86). The
/usr/lib/ld.so.1 is the default linker path dietlibc uses when generating
dynamic binaries, which means that in your build you appear to have tried
to generate a dynamic binary with dietlibc, which cannot work.

So I've compiled mksh against the current version of my dietlibc package
in a qemu-user ppc64el chroot, with the following diff to mksh to make
sure that klibc isn't used but dietlibc is:

diff -Nru mksh-52c/debian/control mksh-52c/debian/control
--- mksh-52c/debian/control     2016-03-06 22:03:49.000000000 +0100
+++ mksh-52c/debian/control     2016-04-06 23:47:50.000000000 +0200
@@ -11,9 +11,9 @@
 # versioned B-D may be used to remove known bogus versions.)
 Build-Depends: bsdmainutils, debhelper (>= 9), ed,
 # better to whitelist, but currently klibc is available for linux-any
-  libklibc-dev [linux-any],
+#  libklibc-dev [linux-any],
   dietlibc-dev (>= 0.33~cvs20111108-5~) [hppa] | dietlibc-doc [hppa],
-  dietlibc-dev [alpha amd64 arm armeb armel armhf i386 ia64 mips mipsel powerpc powerpcspe ppc64 s390 s390x sparc sparc64],
+  dietlibc-dev [alpha amd64 arm armeb armel armhf i386 ia64 mips mipsel powerpc powerpcspe ppc64 ppc64el s390 s390x sparc sparc64],
 # # also for the testsuite (could switch to C.UTF-8 nowadays, though)
   locales [!avr32] | belocs-locales-bin [!avr32]
 # # hard to test against bug

(This adds dietlibc-dev as B-D on ppc64el and removes the klibc B-D
in order to be able to build mksh against dietlibc-dev for testing

If you build mksh directly (not in pbuilder), also apply that patch
against the version in sid and just make sure libklibc-dev is not
installed but my version of dietlibc-dev is.

Note: In my qemu-user chroot I cannot run the full mksh test suite (I
have to run with DEB_BUILD_OPTIONS=nocheck), as qemu doesn't properly
support the signalfd4 syscall on ppc64el, causing the test suite to fail
(also with glibc, unrelated to dietlibc); that test can only be done on
real hardware at the moment.

> The loader /usr/lib/ld.so.1 does NOT exist on my ppc64el system. If I make a symbolic 
> link to the default loader, /lib64/ld64.so.2, it does not work also, as it
> causes a segmentation fault:

That is to be expected: the dynamic loader is libc-specific and you'd
need a dynamic loader for dietlibc, which isn't installed (I'm not even
sure it's built or even fully implemented for ppc*). However, you
shouldn't have a dynamic binary at all...


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: