Hi, 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 purposes.) 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... Regards, Christian
Attachment:
signature.asc
Description: OpenPGP digital signature