This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: --as-needed problem with gnatmake while building 3.4.2 on RH 7.1/RHEL 2.1
On Mon, Sep 06, 2004 at 06:46:44PM +1000, Greg Schafer wrote:
> On Sun, Sep 05, 2004 at 05:03:34AM -0500, Albert Chin wrote:
> > I tried building the 3.4.2 snapshot gcc-3.4.2-20040902.tar.bz2 on
> > Redhat Linux 7.1 and RHEL 2.1 (glibc-2.2.4 based).
>
> <snip>
>
> > ../../gnatmake: error while loading shared libraries: libgcc_s.so.1:
> > cannot open shared object file: No such file or directory
> > make[2]: *** [../../gnatchop] Error 127
> > $ objdump -p gnatmake | egrep 'NEEDED|RPATH'
> > NEEDED libgcc_s.so.1
> > NEEDED libc.so.6
> >
> > The problem is that 'ld' from binutils-2.15 supports as-needed and
> > when gnatmake is built, the link line, using xgcc -Wl,-v, looks like:
> > /opt/TWWfsw/gcc342/i686-redhat-linux7.1/bin/ld --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o ../../gnatmake /usr/lib/crt1.o /usr/lib/crti.o ../../crtbegin.o -L../.. -v [objects] ../rts/libgnat.a ../../prefix.o ../../version.o ../../../libiberty/libiberty.a -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed ../../crtend.o /usr/lib/crtn.o
> >
> > While a dependency to libgcc_s.so.1 is added, no RPATH entry exists to
> > find it. RH 9 and RHEL 3.0 don't run into a problem because they have
> > /lib/libgcc_s.so.1.
> >
> > Should I back down to binutils-2.14 or set LD_LIBRARY_PATH?
>
> Whilst I haven't seen the exact same problem as you have with gnatmake (I
> don't build ADA here), I have seen almost identical behavior when
> bootstrapping new toolchains on older Linux distros. There are some more
> details in "point 1" of this post here:
>
> http://www.diy-linux.org/pipermail/diy-linux-dev/2004-August/000035.html
>
> AFAICT, The `NEEDED' entry for libgcc_s.so.1 should not appear for normal C
> binaries under normal circumstances (is gnatmake even a normal C binary?)
>
> I mailed Jakub Jelinek (developer of the --as-needed stuff) and he
> unfortunately was unable to shed any light for me. All I can say is it works
> fine on newer Glibc based systems, but I see the same unwanted behavior as
> you on older Glibc based systems.
It is a bug in gcc where the system gcc shared libraris are used instead of
the newly built ones. There are several bug reports:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16633
http://gcc.gnu.org/ml/gcc-patches/2004-09/msg00457.html
H.J.