[OE-core] [PATCH] glibc: Fix ldd bug: not a dynamic executable error

Ricardo Ribalda Delgado ricardo.ribalda at gmail.com
Wed Aug 22 13:13:16 UTC 2018


HI Richard

On Wed, Aug 22, 2018 at 3:05 PM <richard.purdie at linuxfoundation.org> wrote:
>
> On Wed, 2018-08-22 at 15:02 +0200, Ricardo Ribalda Delgado wrote:
> > On Wed, Aug 22, 2018 at 3:00 PM <richard.purdie at linuxfoundation.org>
> > wrote:
> > >
> > > On Wed, 2018-08-22 at 14:48 +0200, Ricardo Ribalda Delgado wrote:
> > > > On Wed, Aug 22, 2018 at 2:45 PM <richard.purdie at linuxfoundation.o
> > > > rg>
> > > > wrote:
> > > > >
> > > > > On Tue, 2018-08-21 at 16:58 +0200, Ricardo Ribalda Delgado
> > > > > wrote:
> > > > > > RTLDLIST table does not include /lib/ld-linux-x86-64.so.2,
> > > > > > resulting
> > > > > > on the following error:
> > > > > >
> > > > > > root at qt5122:~# ldd ./qtec_webcam
> > > > > > not a dynamic executable
> > > > > >
> > > > > > Signed-off-by: Ricardo Ribalda Delgado <ricardo.ribalda at gmail
> > > > > > .com
> > > > > > >
> > > > > >
> > > > > > ---
> > > > > >  .../glibc/glibc/0031-ldd-rewrite.patch        | 22
> > > > > > +++++++++++++++++++
> > > > > >  meta/recipes-core/glibc/glibc_2.28.bb         |  1 +
> > > > > >  2 files changed, 23 insertions(+)
> > > > > >  create mode 100644 meta/recipes-core/glibc/glibc/0031-ldd-
> > > > > > rewrite.patch
> > > > >
> > > > > I'm a bit confused as with MACHINE=qemux86-64, building core-
> > > > > image-
> > > > > sato
> > > > > with ldd added to IMAGE_INSTALL, ldd works correctly even
> > > > > though it
> > > > > has
> > > > > /lib/ld-linux-x86-64.so.2 (which is listed in RTLDLIST).
> > > > >
> > > > > We have an automated QA test checking this too:
> > > > >
> > > > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/ru
> > > > > ntim
> > > > > e/cases/ldd.py
> > > > >
> > > > > Which version of the project are you using? How would we
> > > > > reproduce
> > > > > the
> > > > > issue?
> > > >
> > > > I am using yocto-sumo
> > >
> > > I'm not aware of any fixes since sumo in this area...
> > >
> > > > Maybe your tests are run agains an image that has the package lsb
> > > > installed. Which creates symbolic links to the standard locations
> > >
> > > There is no /lib64 in the image and I'm not using or installing
> > > lsb...
> > >
> > > There is significant rewriting done as part of:
> > >
> > > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/recipes-core/gl
> > > ibc/glibc-ld.inc
> > >
> > > What value of RTLDLIST is your build showing?
> >
> > RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
> > /libx32/ld-linux-x32.so.2"
>
> Here I see:
>
> $ MACHINE=qemux86-64 bitbake glibc -e | grep ^RTLDLIST=
> RTLDLIST="/lib/ld-linux-x86-64.so.2"

The output of RTLDLIST that I shared was from
root at qt5122:~# cat /usr/bin/ldd | grep ^RTLD
RTLDLIST="/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2
/libx32/ld-linux-x32.so.2"

If I run your command

pokyuser at c10753884d1a:/workdir/build$ bitbake glibc -e | grep ^RTLDLIST=
RTLDLIST=""

If we look at log.do_compile we can see how the the value from ldd is rewritten:

LC_ALL=C sed -e 's%@RTLD@%/lib/ld-linux-x86-64.so.2%g' -e
's%@VERSION@%2.27%g' -e 's|@PKGVERSION@|(GNU libc) |g' -e
's|@REPORT_BUGS_TO@|<http://www.gnu.org/software/libc/bugs.html>|g' -e
's%@BASH@%/bin/bash%g' -e 's%@TEXTDOMAINDIR@%/usr/share/locale%g' <
ldd.bash.in | LC_ALL=C sed -f
../sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed >
/workdir/build/tmp/work/dbfp4-poky-linux/glibc/2.27-r0/build-x86_64-poky-linux/elf/ldd.new

cat git/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
/LD_TRACE_LOADED_OBJECTS=1/a\
add_env="$add_env LD_LIBRARY_VERSION=\\$verify_out"
s_^\(RTLDLIST=\)\(.*lib\)\(\|64\|x32\)\(/[^/]*\)\(-x86-64\|-x32\)\(\.so\.[0-9.]*\)[
]*$_\1"\2\4\6 \264\4-x86-64\6 \2x32\4-x32\6 \2\3\4\5\6"_

which basically converts
/lib/ld-linux-x86-64.so.2
 into:
 /lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 /libx32/ld-linux-x32.so.2

I agree that this bug is too obvious for not being noticed for a long
time. At least I use ldd a lot when thing fails ;)

Cheers

>
> Not sure why its different without looking at the code but its
> something to look into...
>
> Cheers,
>
> Richard



-- 
Ricardo Ribalda



More information about the Openembedded-core mailing list