0

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%gcc@9.2
-gcc@9.2 +piclibs binutils=binutils-2.33
-gmake@4.2.1
-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!

sucksatnetworking
  • 92
  • 5
  • "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 Feb 01 '20 at 00:31
  • Sorry for the delay. I followed the instructions from Ciro in the following post: https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host – sucksatnetworking Feb 06 '20 at 13:54
  • 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? https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20102 – sucksatnetworking Feb 06 '20 at 13:58
  • For me doing `unset LD_LIBRARY_PATH` and `unset LD_RUN_PATH` first and then running configure and make worked. Thanks to the comment [here](https://stackoverflow.com/questions/35616650/how-to-upgrade-glibc-from-version-2-12-to-2-14-on-centos#comment95249587_38317265) – rashid Aug 28 '21 at 06:42

1 Answers1

0

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362