[Bug driver/26876] Incorrect handling of -B by gfortran driver

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca  2006-03-26 21:28 -------
Subject: Re:   New: Incorrect handling of -B by gfortran driver

> Executing on host: /test/gnu/gcc-4.1/objdir/gcc/testsuite/../gfortran
> -B/test/gn
> u/gcc-4.1/objdir/gcc/testsuite/../
> /test/gnu/gcc-4.1/gcc/gcc/testsuite/gfortran.
> dg/PR19754_2.f90   -O0   -pedantic-errors 
> -L/test/gnu/gcc-4.1/objdir/hppa64-hp-
> hpux11.11/./libgfortran/.libs
> -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/./l
> ibgfortran/.libs -L/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/./libiberty 
> -lm
>    -o ./PR19754_2.exe    (timeout = 300)
> PASS: gfortran.dg/PR19754_2.f90  -O0  (test for excess errors)
> Setting LD_LIBRARY_PATH to
> .:/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/./libg
> fortran/.libs:/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:/
> test/gnu/gcc-4.1/objdir/gcc:.:/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/./lib
> gfortran/.libs:/test/gnu/gcc-4.1/objdir/hppa64-hp-hpux11.11/./libgfortran/.libs:
> /test/gnu/gcc-4.1/objdir/gcc
> /usr/lib/pa20_64/dld.sl: Unsatisfied code symbol '_Jv_RegisterClasses' in load
> m
> odule './PR19754_2.exe'.

Sorry, the subject of this PR is wrong.  I thought that the driver
was not generating the -L option for the build directory with libgcc_s.sl.
However, it's there.

I now think the problem is the link command for libgfortran:

/bin/sh ./libtool --mode=link /test/gnu/gcc-4.1/objdir/./gcc/gfortran -B/test/g
nu/gcc-4.1/objdir/./gcc/ -B/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/bin/ -B
/opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hpux11.11/lib/ -isystem /opt/gnu64/gcc/gcc-4
.1.0/hppa64-hp-hpux11.11/include -isystem /opt/gnu64/gcc/gcc-4.1.0/hppa64-hp-hp
ux11.11/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring -g -O2   -o
 libgfortran.la -rpath /opt/gnu64/gcc/gcc-4.1.0/lib -version-info `grep -v '^#'
  ../../../gcc/libgfortran/libtool-version` -lm  compile_options.lo environ.lo
  error.lo fpu.lo main.lo memory.lo pause.lo stop.lo string.lo select.lo
  all_l4.lo ...

# chatr libgfortran.sl
libgfortran.sl:
         64-bit ELF shared library
         shared library dynamic path search:
             LD_LIBRARY_PATH    enabled  first
             SHLIB_PATH         enabled  second
             embedded path      enabled  third  /opt/gnu64/gcc/gcc-4.1.0/lib
         internal name:
             libgfortran.sl.1
         shared library list:
             libm.2
             libc.2
             libgcc_s.sl

It appears the presence of the embedded path causes the linker to use
the installed version of libgcc_s.sl for the link rather than the new
version.  Then, the definition of LD_LIBRARY_PATH causes the new
version of libgcc_s.sl to be used when the test is executed.

The -rpath option seems to be the problem.

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26876