0
votes

I'm currently trying to compile glibc-2.30 on a linux 3.10.0-1062.9.1.el7.x86_64 system as it is currently running 2.17.
The compile environment consists of the following which have been loaded via spack:
-binutils-2.33.1%[email protected]
[email protected] +piclibs binutils=binutils-2.33
[email protected]
-libcap-2.25
-linux-headers-4.9.10 (dir referenced below as $kern_headers)
-libgd-2.2.4
All required dependencies for the above were also loaded and installed with spack.

I have cloned glibc to $HOME/lib/glibc and checked out glibc-2.30 repo.
From $HOME/lib/glibc_build, I run the following configure to ensure proper use of the above packages:

../glibc/configure --prefix=$HOME/lib/gnu/glibc_v2 CC="$gcc_bin/gcc -m64" --with-headers=$kern_headers CFLAGS=" -O3" CXXFLAGS=" -O3 -std=c++17" --with-binutils=$binutils_base/bin

Followed by:

make -j40

Which compiles without issue. However, when I run

make check

I eventually get multiple instances of the following error:

Inconsistency detected by ld.so: get-dynamic-info.h: 147:
elf_get_dynamic_info: Assertion `info[DT_RPATH] == NULL' failed!

As a sanity check, I run ldd on one of the locale outputted executables which gives:

linux-vdso.so.1 => (0x00007fffc4123000)
libc.so.6 => /lib64/libc.so.6 (0x00002b9080d40000)
$HOME$/lib/gnu/glibc_v2/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002b9080b1c000)

Which makes no sense to me since it is still using the old linker vs the linker from binutils. Also, it points to a directory that is empty since I haven't done make install at this stage to install it to the directory listed in --prefix.

I've tried to run make install regardless, but if I try to compile a test program using the libc.so in the --prefix directory tree using rpath and dynamic-linker compile settings, I get the exact same assertion error message.

Example of failed compile command:

env GCONV_PATH=$HOME/lib/glibc_build/iconvdata \ LOCPATH=$HOME/lib/glibc_build/localedata LC_ALL=C \
$HOME/lib/glibc_build/elf/ld-linux-x86-64.so.2 --library-path \
$HOME/lib/glibc_build:$HOME/lib/glibc_build/math:\
$HOME/lib/glibc_build/elf:$HOME/lib/glibc_build/dlfcn:\
$HOME/lib/glibc_build/nss:$HOME/lib/glibc_build/nis:\
$HOME/lib/glibc_build/rt:$HOME/lib/glibc_build/resolv:\
$HOME/lib/glibc_build/mathvec:$HOME/lib/glibc_build/support:\
$HOME/lib/glibc_build/crypt:$HOME/lib/glibc_build/nptl \
$HOME/lib/glibc_build/csu/test-as-const-ucontext_i \

$HOME/lib/glibc_build/csu/test-as-const-ucontext_i.out; \ ../scripts/evaluate-test.sh csu/test-as-const-ucontext_i $? false false \ $HOME/lib/glibc_build/csu/test-as-const-ucontext_i.test-result Inconsistency detected by ld.so: get-dynamic-info.h: 147: elf_get_dynamic_info: Assertion `info[DT_RPATH] == NULL' failed!

1
"if I try to compile a test program using the libc.so in the --prefix directory tree using rpath and dynamic-linker compile settings, I get the exact same assertion error message." -- what was the command you used?Employed Russian
Sorry for the delay. I followed the instructions from Ciro in the following post: stackoverflow.com/questions/847179/…sucksatnetworking
After some additional digging, I found that the RPATH that is set is related to GCC. I'm currently trying to track down how this is being passed. I found some older information related to the same issue, but I haven't been able to narrow it down. Ideas? debbugs.gnu.org/cgi/bugreport.cgi?bug=20102sucksatnetworking
For me doing unset LD_LIBRARY_PATH and unset LD_RUN_PATH first and then running configure and make worked. Thanks to the comment hererashid

1 Answers

0
votes

As a sanity check, I run ldd on one of the locale outputted executables which gives:

libc.so.6 => /lib64/libc.so.6 (0x00002b9080d40000)
$HOME$/lib/gnu/glibc_v2/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00002b9080b1c000)

Pay not attention to ldd output: it will lie to you, and is mostly meaningless.