--as-needed problem with gnatmake while building 3.4.2 on RH 7.1/RHEL 2.1

--as-needed problem with gnatmake while building 3.4.2 on RH 7.1/RHEL 2.1

[Albert Chin]

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). I first built
binutils-2.15 per
http://gcc.gnu.org/install/specific.html#ix86-*-linux* and installed
into the same prefix as I would 3.4.2:
  $ cd /opt/build
  $ tar jxf binutils-2.15.tar.bz2
  $ cd binutils-2.15
  $ CC=cc CFLAGS="-O2" ./configure --datadir="/opt/TWWfsw/gcc342/share" \
  --disable-shared --program-prefix=g --with-lib-path=/lib:/usr/lib:\
  /usr/local/lib:/usr/i386-redhat-linux/lib --prefix=/opt/TWWfsw/gcc342
  $ make
  # make install

I then built 3.4.2:
  $ cd /opt/build
  $ gtar jxf gcc-3.4.2-20040902.tar.bz2
  $ cd gcc-3.4.2-20040902
  $ gtar zxf gnat-3.15p-i686-pc-redhat71-gnu-bin.tar.gz
  $ cd gnat-3.15p-i686-pc-linux-gnu-bin
  $ rm -rf /opt/build/gnat
  $ make ins-all prefix=/opt/build/gnat
  $ export PATH=/opt/build/gnat/bin:$PATH
  $ mkdir /opt/build/gcc-3.4.2-20040902-objdir
  $ cd /opt/build/gcc-3.4.2-20040902-objdir
  $ GNATBIND=/opt/build/gnat/bin/gnatbind CC=gcc \
  /opt/build/gcc-3.4.2-20040902/configure --with-included-gettext \
  --enable-libgcj --enable-__cxa_atexit \
  --with-gnu-as --with-as="/opt/TWWfsw/gcc342/i686-pc-linux-gnu/bin/as" \
  --with-gnu-ld --with-ld="/opt/TWWfsw/gcc342/i686-pc-linux-gnu/bin/ld"
  --datadir="/opt/TWWfsw/gcc342/share" \
  --with-local-prefix="/opt/TWWfsw/gcc342" --prefix="/opt/TWWfsw/gcc342"
  $ make bootstrap
  $ cd /opt/build/gcc-3.4.2-20040902-objdir/gcc
  $ make gnatlib_and_tools
  ...
  ../../xgcc -B../../ -DIN_GCC   `echo -g -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes    |sed -e 's/-pedantic//g' -e 's/-Wtraditional//g'`  -o ../../gnatmake b_gnatm.o ctrl_c.o ali.o ali-util.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o krunch.o lib.o make.o makeusg.o mlib.o mlib-fil.o mlib-prj.o mlib-tgt.o mlib-utl.o namet.o nlists.o opt.o osint.o osint-m.o output.o prj.o prj-attr.o prj-com.o prj-dect.o prj-env.o prj-err.o prj-ext.o prj-nmsc.o prj-pars.o prj-part.o prj-proc.o prj-strt.o prj-tree.o prj-util.o rident.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o sinfo.o sinput.o sinput-c.o sinput-p.o snames.o stand.o stringt.o styleg.o stylesw.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o  uname.o urealp.o usage.o widechar.o  \
      ../rts/libgnat.a  ../../prefix.o ../../version.o ../../../libiberty/libiberty.a  
  ...
  rm -f tools/mlib-tgt.adb; ln -s
  /opt/build/gcc-3.4.2-20040902/gcc/ada/5lml-tgt.adb tools/mlib-tgt.adb;
  touch ../stamp-tools
  ../../gnatmake -c -I../rts -I. -I/opt/build/gcc-3.4.2-20040902/gcc/ada gnatchop --GCC="../../xgcc -B../../ -g      -gnatpg -gnata"
  ../../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?

-- 
albert chin (china@thewrittenword.com)

Re: --as-needed problem with gnatmake while building 3.4.2 on RH 7.1/RHEL 2.1

[Greg Schafer]

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.

Regards
Greg
--
http://www.diy-linux.org/

Re: --as-needed problem with gnatmake while building 3.4.2 on RH 7.1/RHEL 2.1

[H. J. Lu]

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.