On a Debian 9 system (x86-64), trying to build anything will be impossible with Yocto. Tried both with last version of pyro and with master. The problems is than when trying to build autoconf-native, the m4 binary previously built (on the recipe m4-native) will segfault. The segfault is caused by the uninative libc that is currently downloaded and used. I have disabled this feature by setting https://127.0.0.1 as UNINATIVE_URL on local.conf (couldn't find a better way to disable it) and I was able to build everything without problem. Then I tried to create my own uninative tarball, via bitbake uninative-tarball and used that tarball on another Debian 9 machine and the same happened. The issue isn't on the uninative tarball itself, but on something weird that happens with the m4 binary. To discard an issue with my system itself I was able to reproduce this on fresh Debian 9 chroot: $ create chroot debian 9 x86_64: $ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev xterm python $ bitbake autoconf-native [ fail due to m4 crash ]
On my system I can see this: $ find |grep bin/m4$|xargs md5sum|sort 3dbb9601051793a76c305934171fc383 ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/image/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4 69309279ba64ef584bcd294418b26017 ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 69309279ba64ef584bcd294418b26017 ./tmp/work/x86_64-linux/autoconf-native/2.69-r11/recipe-sysroot-native/usr/bin/m4 69309279ba64ef584bcd294418b26017 ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/sysroot-destdir/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4 So two versions of the m4 binary where built: 1) The first one (3dbb9601051793a76c305934171fc383) has as binary interpreter the system one (/lib64/ld-linux-x86-64.so.2) and works as expected: $ file ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/image/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4 ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/image/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=86389d326e59995bf0096ff858fa4c3dc76c6c3b, not stripped $ ls -l ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/image/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4 ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 1 clopez clopez 168328 Jul 12 21:58 ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/image/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4 $ ./tmp/work/x86_64-linux/m4-native/1.4.18-r0/image/home/igalia/clopez/yocto/tmp/work/x86_64-linux/m4-native/1.4.18-r0/recipe-sysroot-native/usr/bin/m4 --help [ ok: prints the help ] 2) The second one (69309279ba64ef584bcd294418b26017) has as interpreter the one from the uninative tarball (tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2), different binary size, and crashes always. $ file ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/igalia/clopez/yocto/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=86389d326e59995bf0096ff858fa4c3dc76c6c3b, for GNU/Linux 2.6.32, stripped ls -l ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 143504 Jul 12 21:58 ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help Segmentation fault
FYI: I found a better way to disable uninative: Add in local.conf: INHERIT_remove = "uninative" And now I'm able to reproduce the issue easily by simply rebuilding m4-native with that setting or not. If I do: 1) When I have in local.conf INHERIT_remove = "uninative" I get this: $ bitbake -c cleanall m4-native && bitbake m4-native [...] $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 2 clopez clopez 142592 Jul 12 22:37 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=247f5052ae825d0a0e18fd1b02d9565c0ac8282a, stripped $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007ffd85b30000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f055410e000) /lib64/ld-linux-x86-64.so.2 (0x0000556cea280000) $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help [ ok: works... prints the help ] 2) When I leave local.conf with default values I get this: $ bitbake -c cleanall m4-native && bitbake m4-native [...] $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 2 clopez clopez 143496 Jul 12 22:39 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/igalia/clopez/yocto/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=247f5052ae825d0a0e18fd1b02d9565c0ac8282a, for GNU/Linux 2.6.32, stripped $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007ffcb65fc000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda4bfde000) /home/igalia/clopez/yocto/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000055841419f000) $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help Segmentation fault
Now we've upgraded glibc to the latest verison it would be good to see if a uninative built using this has the same issues...
(In reply to comment #3) > Now we've upgraded glibc to the latest verison it would be good to see if a > uninative built using this has the same issues... When is "now" ? This failure I describe happened to me both with poky master (commit: 81498aac9560fbeaeb58eaada32ce80e0ea51628) which is the last available AFAIK on git://git.yoctoproject.org/poky.git as also with the pyro branch (commit: 81498aac9560fbeaeb58eaada32ce80e0ea51628) on the same repository.
My hunch is that you don't have the en_US.UTF-8 locale generated (dpkg-reconfigure locales). Can you check that? We switch to a specific locale for build sanity but it appears we don't check the switch worked, and glibc is *terrible* at reporting errors when a non-existant locale is specified.
(In reply to comment #5) > My hunch is that you don't have the en_US.UTF-8 locale generated > (dpkg-reconfigure locales). Can you check that? We switch to a specific > locale for build sanity but it appears we don't check the switch worked, and > glibc is *terrible* at reporting errors when a non-existant locale is > specified. I use the locale en_US.UTF-8 and I have it generated. Just in case I have double-checked to regenerate it via dpkg-reconfigure locales and the problems continues to be reproducible
Hi, I executed a full build (wo sstates) of m4 in my Debian9 system with master rev 81498aac9560fbeaeb58eaada32ce80e0ea51628 and everything works as expected. My locale settings are set to en_US.UTF-8. Regards, Anibal
(In reply to comment #7) > Hi, > > I executed a full build (wo sstates) of m4 in my Debian9 system with master > rev > 81498aac9560fbeaeb58eaada32ce80e0ea51628 and everything works as expected. > > My locale settings are set to en_US.UTF-8. > > Regards, > Anibal Really strange, I tested this not only on my development machine but also on a new fresh chroot with Debian 9 and on another machine with Debian 9. Reproducible on the 3 cases. Are you also running a Debian kernel? Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 GNU/Linux
(In reply to comment #8) > (In reply to comment #7) > > Hi, > > > > I executed a full build (wo sstates) of m4 in my Debian9 system with master > > rev > > 81498aac9560fbeaeb58eaada32ce80e0ea51628 and everything works as expected. > > > > My locale settings are set to en_US.UTF-8. > > > > Regards, > > Anibal > > Really strange, I tested this not only on my development machine but also on > a new fresh chroot with Debian 9 and on another machine with Debian 9. > Reproducible on the 3 cases. > > Are you also running a Debian kernel? > Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 > GNU/Linux Yes the same kernel, the only diff is that i upgraded my debian from 8 vesion but i don't expect be affected by the upgrade. Anibal
Can you run segfaulting command under strace and show the output here?
Created attachment 3871 [details] [OK] strace -f tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help (without uninative)
Created attachment 3872 [details] [segfault] strace -f tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help (with uninative)
Attached the output of running "strace -f tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help" (with both versions of m4: with and without uninative)
Created attachment 3873 [details] strace -f tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help Attached strace output from my debian 9 system (with uninative)
Carlos, can you do the following: 1. Apply this patch to include debug info into m4 binary and disable stripping: diff --git a/meta/recipes-devtools/m4/m4-native_1.4.18.bb b/meta/recipes-devtools/m4/m4-native_1.4.18.bb index 06d8aa244e5..3fb6555ae11 100644 --- a/meta/recipes-devtools/m4/m4-native_1.4.18.bb +++ b/meta/recipes-devtools/m4/m4-native_1.4.18.bb @@ -4,6 +4,8 @@ inherit native INHIBIT_AUTOTOOLS_DEPS = "1" DEPENDS += "gnu-config-native" +CFLAGS_append = " -g " +INHIBIT_SYSROOT_STRIP = "1" do_configure() { install -m 0644 ${STAGING_DATADIR}/gnu-config/config.sub . 2. rebuild m4 bitbake m4-native 3. run m4 to produce core dump: ulimit -c unlimited tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help it should segfault and dump core. The message should be: Segmentation fault (core dumped) 3. run gdb with the core: gdb tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 core 4. show the output of 3. here
(In reply to comment #15) > Carlos, can you do the following: > > 1. Apply this patch to include debug info into m4 binary and disable > stripping: > diff --git a/meta/recipes-devtools/m4/m4-native_1.4.18.bb > b/meta/recipes-devtools/m4/m4-native_1.4.18.bb > index 06d8aa244e5..3fb6555ae11 100644 > --- a/meta/recipes-devtools/m4/m4-native_1.4.18.bb > +++ b/meta/recipes-devtools/m4/m4-native_1.4.18.bb > @@ -4,6 +4,8 @@ inherit native > > INHIBIT_AUTOTOOLS_DEPS = "1" > DEPENDS += "gnu-config-native" > +CFLAGS_append = " -g " > +INHIBIT_SYSROOT_STRIP = "1" > > do_configure() { > install -m 0644 ${STAGING_DATADIR}/gnu-config/config.sub . > > 2. rebuild m4 > > bitbake m4-native > > 3. run m4 to produce core dump: > ulimit -c unlimited > tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help > > it should segfault and dump core. The message should be: > Segmentation fault (core dumped) > > 3. run gdb with the core: > gdb tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 core > > 4. show the output of 3. here Funny enough, either setting CFLAGS_append = " -g " or INHIBIT_SYSROOT_STRIP = "1" on m4-native makes the bug way (that is: the produced binary not longer crashes) I have hunted down the problem, and it seems to be caused by patchelf-uninative. But the problem only triggers when the binary has been built without "-g" and .note and .comment sections have been removed from it with the strip utility (something that poky/bitbake/yocto does by default). patchelf-uninative will not trigger this crash if the binary was built with "-g" or if .note and .comment sections were not removed by strip from the binary after building it. I hope that what I describe below is not too messy to follow. I have broken it in several steps to make easier to read and I will be attaching the resulting m4 binaries of each step. Perhaps some of you can detect something weird on them. To reproduce this issue I can do the following: 1) Apply the following patch in poky: diff --git a/meta/recipes-devtools/m4/m4-native_1.4.18.bb b/meta/recipes-devtools/m4/m4-native_1.4.18.bb index 06d8aa244e..8e51672280 100644 --- a/meta/recipes-devtools/m4/m4-native_1.4.18.bb +++ b/meta/recipes-devtools/m4/m4-native_1.4.18.bb @@ -4,6 +4,7 @@ inherit native INHIBIT_AUTOTOOLS_DEPS = "1" DEPENDS += "gnu-config-native" +INHIBIT_SYSROOT_STRIP = "1" do_configure() { install -m 0644 ${STAGING_DATADIR}/gnu-config/config.sub . 2) After building m4-native as usual, now disable the uninative feature so patchelf-uninative doesnt run over the binary automatically. Append to local.conf: INHERIT_remove = "uninative" 3) cleanall and rebuild m4-native $ bitbake -c cleanall m4-native && bitbake m4-native 4) You end with a working m4 binary at tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 5) Now lets do manually what Yocto would have done automatically with this binary if we used the default values, and that end with a crashing binary. # Do a copy of the binary that was produced in the first place $ cp tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ~/toshare/m4-original # Check that it works $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help|wc -l 64 # Get some info about it: $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 168328 Jul 17 22:11 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007ffdb8299000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007efef1a2b000) /lib64/ld-linux-x86-64.so.2 (0x000055fcfc4a1000) $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e355af258757b6ab2ffc454669e90970d6208a5b, not stripped 6) Now strip it as Yocto will have been done automatically for it (if we had not set INHIBIT_SYSROOT_STRIP = "1" in the recipe): $ strip --remove-section=.comment --remove-section=.note tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 # Save another copy of it cp tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ~/toshare/m4-stripped # Check that still works $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help|wc -l 64 # Get some info about it $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 142592 Jul 17 22:14 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007ffda3b11000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1d8a848000) /lib64/ld-linux-x86-64.so.2 (0x0000556a0c4a7000) $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e355af258757b6ab2ffc454669e90970d6208a5b, stripped 7) Now run patchelf-uninative over it as Yocto will have been done automatically for it (if we had not set INHERIT_remove = "uninative" in local.conf): $ tmp/sysroots-uninative/x86_64-linux/usr/bin/patchelf-uninative --set-interpreter $(pwd)/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 # Save another copy of it cp tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ~/toshare/m4-stripped-patchedelf # Check that now the binary is broken $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help Segmentation fault # Get some info about it $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 143504 Jul 17 22:21 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007fffcf5c8000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f97f968b000) /home/igalia/clopez/yocto/yoctobug-11785/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000055ea6ccc5000) $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/igalia/clopez/yocto/yoctobug-11785/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=e355af258757b6ab2ffc454669e90970d6208a5b, for GNU/Linux 2.6.32, stripped 8) Now repeat the experiment of 7) but setting as interpreter the same than it had. # Recover copy before 7 $ cp ~/toshare/m4-stripped tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 # Check that still works: $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help|wc -l 64 # Get some info: $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 142592 Jul 17 22:23 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=e355af258757b6ab2ffc454669e90970d6208a5b, stripped $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007fffed3ca000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2e0facf000) /lib64/ld-linux-x86-64.so.2 (0x000055b266a90000) # Now run patchelf to change the intreter to /lib64/ld-linux-x86-64.so.2 # Wow! what should have been a NO-OP operation makes a different binary that now crashes $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help Segmentation fault # Get some info about it $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 143424 Jul 17 22:24 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007fffe6198000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd76cdb000) /lib64/ld-linux-x86-64.so.2 (0x00005649e04c8000) $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e355af258757b6ab2ffc454669e90970d6208a5b, for GNU/Linux 2.6.32, stripped # And finally do a copy of it $ cp tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ~/toshare/m4-stripped-patchedelf-sameinterpreter 9) Now repeat experiment 7) but using the original binary non-stripped from step 5. # Recover copy from 5 $ cp ~/toshare/m4-stripped tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 # Check that works $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help|wc -l 64 # Run patchelf over it as Yocto would have done: $ tmp/sysroots-uninative/x86_64-linux/usr/bin/patchelf-uninative --set-interpreter $(pwd)/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 # Check that works # Wohoo! So now it works? the only difference is that this binary was not stripped to remove the .comment and .note sections $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help|wc -l 64 # Get some info about it $ ls -l tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 -rwxr-xr-x 3 clopez clopez 172176 Jul 17 22:37 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ ldd tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 linux-vdso.so.1 (0x00007fffe3d75000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f3481c05000) /home/igalia/clopez/yocto/yoctobug-11785/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x000055624de46000) $ file tmp/sysroots-components/x86_64/m4-native/usr/bin/m4tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/igalia/clopez/yocto/yoctobug-11785/build/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=e355af258757b6ab2ffc454669e90970d6208a5b, for GNU/Linux 2.6.32, not stripped # Do a copy of it cp tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ~/toshare/m4-patchedelf
Created attachment 3875 [details] m4_binaries_yocto_bug_11785.tar.xz: tar.xz with the binaries described in #comment:16 m4-original m4-patchedelf m4-stripped m4-stripped-patchedelf m4-stripped-patchedelf-sameinterpreter
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Hi, > > > > > > I executed a full build (wo sstates) of m4 in my Debian9 system with master > > > rev > > > 81498aac9560fbeaeb58eaada32ce80e0ea51628 and everything works as expected. > > > > > > My locale settings are set to en_US.UTF-8. > > > > > > Regards, > > > Anibal > > > > Really strange, I tested this not only on my development machine but also on > > a new fresh chroot with Debian 9 and on another machine with Debian 9. > > Reproducible on the 3 cases. > > > > Are you also running a Debian kernel? > > Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u2 (2017-06-26) x86_64 > > GNU/Linux > > Yes the same kernel, the only diff is that i upgraded my debian from 8 > vesion but i don't expect be affected by the upgrade. > > Anibal I think I know why you can't reproduce it. I have /usr/lib/gold-ld as first directory on my PATH (which is a way of setting the gold linker by default) $ echo $PATH /usr/lib/gold-ld:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin $ ld -v GNU gold (GNU Binutils for Debian 2.28) 1.14 By removing that from my path, and triggering a build from scratch ( that is: source poky/oe-init-build-env testbuild && bitbake m4-native ; its not enough with just doing a cleanall on m4-native) the problem is not longer reproducible. So this weird bug seems to be a bad interaction somewhere between the gold linker, strip and patchelf :\
Reproduced on docker debian 9 image
using patchelf from Debian worked just fine: $ bitbake -c cleanall m4-native && bitbake m4-native $ strip --remove-section=.comment --remove-section=.note tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 $ patchelf --set-interpreter $(pwd)/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2 tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 warning: working around a Linux kernel bug by creating a hole of 40960 bytes in ‘tmp/sysroots-components/x86_64/m4-native/usr/bin/m4’ $ tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help |wc -l 64 I'm going to look at how patchelf is built in Debian. They probably have a patch to fix this issue. We'll just need to apply it.
Looks like debian patchelf doesn't have almost any patches. I'm guessing that meta/recipes-devtools/patchelf/patchelf/avoidholes.patch causes this issue. Haven't figured out yet how to test it though.
confirmed that the issue is caused by avoidholes.patch: rebuilt uninative tarball with this patch applied: --- a/meta/recipes-devtools/patchelf/patchelf_0.9.bb +++ b/meta/recipes-devtools/patchelf/patchelf_0.9.bb @@ -2,9 +2,11 @@ SRC_URI = "http://nixos.org/releases/${BPN}/${BPN}-${PV}/${BPN}-${PV}.tar.bz2 \ file://Skip-empty-section-fixes-66.patch \ file://handle-read-only-files.patch \ file://Increase-maxSize-to-64MB.patch \ - file://avoidholes.patch \ " +# file://avoidholes.patch + + LICENSE = "GPLv3" SUMMARY = "Tool to allow editing of RPATH and interpreter fields in ELF binaries" copied it to tmp: cp tmp/deploy/sdk/x86_64-nativesdk-libc.tar.bz2 /tmp/ used it for the build by setting 2 variables in conf/local.conf: UNINATIVE_URL ?= "file:///tmp/" UNINATIVE_CHECKSUM[x86_64] ?= "169a0dbc4781c9f6e7d79ef3c8cbaa56f6be000cccbff7da809262e967fce618" rebuilt m4-native: export PATH=/usr/lib/gold-ld/:$PATH rm -rf tmp && bitbake -c cleanall m4-native && bitbake m4-native run m4: $ ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help | wc -l 64 next step would be to understand what patch is doing and why it breaks the binary
More info: The issue is only reproducible with gold linker that produces executables of "DYN (Shared object file)". This is not the case with standard ld or even with gold older versions. They all produce executables of "EXEC (Executable file)" patchelf is aware of the above and works just fine with executables in DYN format. However, it doesn't work with them after applying avoidholes patch. The patch is already in upstream master: https://github.com/NixOS/patchelf/commit/c4deb5e9e1ce9c98a48e0d5bb37d87739b8cfee4. I've tested patchelf from master with and without this patch and confirmed that the patch makes patchelf to break stripped executables of DYN type produced by gold linker. ldd doesn't recognise broken executables as dynamically linked. It reports "not a dynamic executable" for stripped and patched m4 binary. not stripped patched m4 seems to work (m4 --help doesn't segfault), but it's also broken as ldd report is the same as for stripped patched m4: "not a dynamic executable"
Carlos, can you try this fix please? diff --git a/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch b/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch index a273688b988..62575f53047 100644 --- a/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch +++ b/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch @@ -122,6 +122,7 @@ Index: patchelf-0.9/src/patchelf.cc if (isExecutable) { if (startOffset >= startPage) { debug("shifting new PT_LOAD segment by %d bytes to work around a Linux kernel bug\n", startOffset - startPage); ++ startPage = startOffset; - } else { - size_t hole = startPage - startOffset; - /* Print a warning, because the hole could be very big. */ @@ -132,7 +133,7 @@ Index: patchelf-0.9/src/patchelf.cc - growFile(fileSize + hole); - startOffset += hole; } - startPage = startOffset; +- startPage = startOffset; } - It worked for me just fine. Here is what I did: 1. applied above patch 2. rebuild uninative tarball and copied it to /tmp rm -rf tmp/ bitbake uninative-tarball cp tmp/deploy/sdk/x86_64-nativesdk-libc.tar.bz2 /tmp/ $ sha256sum /tmp/x86_64-nativesdk-libc.tar.bz2 428bed8aa516fad7e87be5908313476ce60a56a3d4b91d92a3d30a693c8c27d1 /tmp/x86_64-nativesdk-libc.tar.bz2 3. Added 2 lines to my conf/local.conf to use it: UNINATIVE_URL ?= "file:///tmp/" UNINATIVE_CHECKSUM[x86_64] ?= "428bed8aa516fad7e87be5908313476ce60a56a3d4b91d92a3d30a693c8c27d1" 4. Changed linker to gold: export PATH=/usr/lib/gold-ld/:$PATH ld -v GNU gold (GNU Binutils for Debian 2.28) 1.14 5. Rebuilt autoconf-native: rm -rf tmp/ && bitbake autoconf-native -c cleanall && bitbake autoconf-native 6. Run m4 just to confirm it works (this is optional as it definitely worked during autoconf build) ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 --help | wc -l 64 7. Confirmed that m4 binary was patched: file ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /home/ed/git/yocto/poky/build-11785/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2, BuildID[sha1]=241678f2ba5f910aaac0c6a8a0c53a422a28c90c, for GNU/Linux 2.6.32, stripped 8. Confirmed that .interp section header was moved to the end of table: readelf -a ./tmp/sysroots-components/x86_64/m4-native/usr/bin/m4 |grep interp [28] .interp PROGBITS 000000000002d000 00023000 [Requesting program interpreter: /home/ed/git/yocto/poky/build-11785/tmp/sysroots-uninative/x86_64-linux/lib/ld-linux-x86-64.so.2] 08 .interp 09 .interp .note.ABI-tag NOTE: I'm not entirely sure this is a proper fix as I don't fully understand patchelf code. I'll need Richard's help on this as he is the author of original change.
Sent for review: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139967.html
after re(In reply to comment #24) > Carlos, can you try this fix please? > diff --git a/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch > b/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch > index a273688b988..62575f53047 100644 > --- a/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch > +++ b/meta/recipes-devtools/patchelf/patchelf/avoidholes.patch > @@ -122,6 +122,7 @@ Index: patchelf-0.9/src/patchelf.cc > if (isExecutable) { > if (startOffset >= startPage) { > debug("shifting new PT_LOAD segment by %d bytes to work around > a Linux kernel bug\n", startOffset - startPage); > ++ startPage = startOffset; > - } else { > - size_t hole = startPage - startOffset; > - /* Print a warning, because the hole could be very big. */ > @@ -132,7 +133,7 @@ Index: patchelf-0.9/src/patchelf.cc > - growFile(fileSize + hole); > - startOffset += hole; > } > - startPage = startOffset; > +- startPage = startOffset; > } > > - > > It worked for me just fine. > > Here is what I did: > > 1. applied above patch > > 2. rebuild uninative tarball and copied it to /tmp Tried it. This fixes the problem also here. Thanks for the fix !! :)
The fix has been merged to poky master. commit id: ec5c4e97c8c11a9ff93c4c4f653ad6cfd55fa7fa
(In reply to comment #27) > The fix has been merged to poky master. commit id: > ec5c4e97c8c11a9ff93c4c4f653ad6cfd55fa7fa Thanks for the fix :) I think a new uninative tarballs at http://downloads.yoctoproject.org/releases/uninative/ should be generated in order for the fix to be complete, shouldn't it?
*** Bug 11854 has been marked as a duplicate of this bug. ***
Let's wait for uninative tarball to be published.
New uninative tarball v1.7 has been released: http://downloads.yoctoproject.org/releases/uninative/1.7/ And used for yocto distribution: http://cgit.openembedded.org/openembedded-core/commit/