GCC-3.4.3 doesn't "see" glibc2 (2.3.3)

alupu@verizon.net alupu@verizon.net
Sun Feb 6 12:06:00 GMT 2005

 Hello GCC/GNU experts:

Please help me with this problem.
I cannot recompile gcc-3.4.3 against my newly installed
glibc-2.3.3 (in /usr/local/glibc2).  In spite of my best efforts,
GCC keeps using my old /lib/libc.so.6 (2.2.93) for its rebuild.
System: "i686-pc-linux-gnu", kernel 2.6.9.
Started as a RedHat-8.0 (2.4.14), lately in a
gradual "modernization" process,
to move it from an "RPM-binary-'/lib'" centric to
a "'/usr/local'-compiled-from-sources" type system.

Now I'm almost there; for example, lately moved from
/lib/i686/libc.so.6 -> libc-2.2.93.so
/usr/local/glibc2/lib/libc.so.6 -> libc-2.3.3.so
and from /usr/bin/gcc-3.2 to /usr/local/bin/gcc-3.4.3.

Most recently, many "vital" packages, such as bash-3.0,
fileutils-4.1, sh-utils-2.0, binutils-2.15.94, etc.
have been successfully (and effortlessly) compiled
in /usr/local/ against the new glibc2 (2.3.3) and are
now happily running from /usr/local/bin, lib, etc.).
Obviously, for this to happen so "smoothly",
the new PATH favors '/usr/local/bin' over '/bin',
and the new 'ld.so.conf', in conjunction with the
new ldconfig, has set up some pretty links in
(excerpt - two lines around the 'libc' entry)
libcom_err.so (libc6) => /usr/kerberos/lib/libcom_err.so
libc.so.6 (ELF, OS ABI: Linux 2.0.0) =>
libbz2.so.1.0 (libc6) => /usr/local/lib/libbz2.so.1.0

PROBLEM (the only fly in the above beautiful ointment):
I CANNOT "bootstrap" the new gcc (3.4.3) to "recognize" the
new glibc2 and dynamic linker.
No matter what (and how) I do, I invariably get,

[]# ldd /usr/local/bin/gcc
libc.so.6 => /lib/i686/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2

despite my damnedest efforts.
As a comparison,
[]# ldd /usr/bin/gcc-old (the v3.2)
libc.so.6 => /lib/i686/libc.so.6
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
i.e. no progress at all!!

For reference:
[]# gcc -###
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --enable-threads --enable-__cxa_atexit
Thread model: posix
gcc version 3.4.3

Any new program (compiled with the new gcc-3.4.3!) comes
out perfect without any extra effort (switches, arguments,
flags to 'configure', 'make', etc.)
I pick a few relevant examples (slightly edited for clarity):

[]# ldd /usr/local/bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /usr/local/lib/libtermcap.so.2
libintl.so.3 => /usr/local/lib/libintl.so.3
libc.so.6 => /usr/local/lib/libc.so.6
libdl.so.2 => /usr/local/glibc2/lib/libdl.so.2
/usr/local/glibc2/lib/ld-linux.so.2 =>

[]# ldd /usr/local/bin/ld
linux-gate.so.1 => (0xffffe000)
libintl.so.3 => /usr/local/lib/libintl.so.3
libc.so.6 => /usr/local/lib/libc.so.6
libdl.so.2 => /usr/local/glibc2/lib/libdl.so.2
/usr/local/glibc2/lib/ld-linux.so.2 =>

-- The canonical "Hello World" in C (printf ...):
[]# gcc -o test test.c
[]# ldd test
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /usr/local/glibc2/lib/libc.so.6
/usr/local/glibc2/lib/ld-linux.so.2 =>

-- The canonical "Hello World" in C++ (cout << ...):
[]# g++ -o test test.cpp
[]# ldd test
linux-gate.so.1 => (0xffffe000)
libstdc++.so.6 => /usr/local/lib/libstdc++.so.6
libm.so.6 => /usr/local/glibc2/lib/libm.so.6
libgcc_s.so.1 => /usr/local/lib/libgcc_s.so.1
libc.so.6 => /usr/local/glibc2/lib/libc.so.6
/usr/local/glibc2/lib/ld-linux.so.2 =>
usr/local/glibc2/lib/ld-linux.so.2 (0xb7fec000)

-- Even the canonical 'glibc_version' looks good:
[]# gcc -o glibc_version glibc_version.c
[]# ./glibc_version
[]# ldd glibc_version
linux-gate.so.1 => (0xffffe000)
libc.so.6 => /usr/local/glibc2/lib/libc.so.6 (0xb7ec1000)
/usr/local/glibc2/lib/ld-linux.so.2 =>
/usr/local/glibc2/lib/ld-linux.so.2 (0xb7fec000)

I've tried all the latest tricks of the trade, among them,
in 'configure' and/or 'make bootstrap'
-- env LDFLAGS = -Wl,--dynamic-linker=
-- Editing a similar LDFLAGS in the main Makefile
-- At times playing with LD_LIBRARY_PATH
(/usr/local/lib/, etc.)
-- At times playing with symlinks to the new glibc2,
all (and then some) to NO avail!

On each try I start from zero (i.e. fully deleting subdirs,
gcc-3.4.3 and OBJDIR).
By the way, gcc-3.4.3 and OBJDIR are "by the book" - immediate
and independent subdirectories of /usr/local/GCC.
And yes, each and every time I edit the "spec" file,
*link: ... to
-dynamic-linker /usr/local/glibc2/lib/ld-linux.so.2
(from /lib/ld-linux.so.2)

No matter what I do, I keep getting the discouraging
results detailed above, and a little extra here:
[]# ldd /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.3/cc1
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fee000)

although, for example
[]# gcc -print-file-name=libc.so.6
[]# gcc -print-file-name=libgcc.a

Thanks in advance,
-- Alex

More information about the Gcc-help mailing list