[Bug nptl/21501] New: get-dynamic-info assertion incorrectly triggered for i686 on x86_64 : 'Assertion `info[DT_RPATH] == NULL' failed!'

["jason.vas.dias at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=21501

            Bug ID: 21501
           Summary: get-dynamic-info assertion incorrectly triggered for
                    i686 on x86_64 : 'Assertion `info[DT_RPATH] == NULL'
                    failed!'
           Product: glibc
           Version: 2.25
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: jason.vas.dias at gmail dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: 2.26

This did not happen when building glibc-2.24 in an identical way, for i686
(Intel Atom) on an x86_64 (Haswell) :

  $ ./ld.so --list /tmp/hello32
Inconsistency detected by ld.so: get-dynamic-info.h: 143: elf_get_dynamic_info:
Assertion `info[DT_RPATH] == NULL' failed!

But neither the glibc-2.25 (-m32) ld.so , NOR the test file made with
  $ gcc -m32 -o /tmp/hello32 ~/hello.c
have any DT_RPATH or DT_RUNPATH set ! :
  $ readelf -d /lib32/ld-linux.so.2 | grep PATH
  0x0000000f (RPATH)                      Library rpath: []
  $ strings /tmp/hello32 | grep ld-linux
  /lib32/ld-linux.so.2
  $ readelf -d /tmp/hello32 | grep PATH
  $
Aha ! It appears my build of the 32-bit ld.so has an EMPTY RPATH .
I don't know how it got there, because I did not specify that glibc
should use an RPATH .  

The configuration arguments and environment variable settings for the 32-bit
build that resulted in the useless ld.so were:

  $ /usr/os_src/glibc/configure --prefix=/usr --libdir=/usr/lib32 \ 
    --enable-shared --without-selinux --disable-werror \
    --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu \
    --target=i686-pc-linux-gnu

ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-std=gnu11 -m32 -march=i686 -mtune=atom -O2 -g -fPIC
-pipe'
ac_cv_env_CPPFLAGS_set=set
ac_cv_env_CPPFLAGS_value=
ac_cv_env_CPP_set=set
ac_cv_env_CPP_value='cpp -m32'
ac_cv_env_CXXFLAGS_set=set
ac_cv_env_CXXFLAGS_value='-std=gnu++11 -m32 -march=i686 -mtune=atom -O2 -g
-fPIC -pipe'
ac_cv_env_CXX_set=set
ac_cv_env_CXX_value='g++ -m32'
ac_cv_env_LDFLAGS_set=set
ac_cv_env_LDFLAGS_value=
ac_cv_env_LIBS_set=set
ac_cv_env_LIBS_value=
ac_cv_env_build_alias_set=set
ac_cv_env_build_alias_value=i686-pc-linux-gnu
ac_cv_env_host_alias_set=set
ac_cv_env_host_alias_value=i686-pc-linux-gnu
ac_cv_env_target_alias_set=set
ac_cv_env_target_alias_value=i686-pc-linux-gnu
ac_cv_host=i686-pc-linux-gnu
ac_cv_objext=o
ac_cv_path_BASH_SHELL=/usr/bin/bash
ac_cv_path_INSTALL_INFO=/usr/sbin/install-info
ac_cv_path_PERL=/usr/bin/perl
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AS=/usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/as
ac_cv_prog_AWK=gawk
ac_cv_prog_BISON=bison
ac_cv_prog_CC='gcc -m32'
ac_cv_prog_LD=/usr/lib64/gcc/x86_64-pc-linux-gnu/5.4.0/../../../../x86_64-pc-linux-gnu/bin/ld
ac_cv_prog_MAKE=make
ac_cv_prog_MAKEINFO=makeinfo
ac_cv_prog_MSGFMT=msgfmt
ac_cv_prog_NM=nm
ac_cv_prog_PYTHON_PROG=python
ac_cv_prog_SED=sed
ac_cv_prog_ac_ct_READELF=readelf
ac_cv_prog_cc_g=yes
ac_cv_prog_cxx_g=yes



I don't know how any RPATH got into the ld.so, let alone an EMPTY one .
There is no occurrence of the string 'RPATH' or 'RUNPATH' anywhere in
the config.log of the 'configure' command (extract shown above) .

As I said, building 32-bit executables used to work fine on glibc 2.24 -
any ideas why this is now happening ?

Maybe I should raise a binutils bug on the fact that ld(1) is inserting
an EMPTY RPATH ? This is a bit silly - what effect is an EMPTY RPATH meant
to have ? But where is this empty RPATH coming from ? I did not specify it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.