------- 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
