Bug 21547 - GMP/MPFR shared libraries not in LD_LIBRARY_PATH: failure to build libgfortran
Summary: GMP/MPFR shared libraries not in LD_LIBRARY_PATH: failure to build libgfortran
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on:
Blocks:
 
Reported: 2005-05-13 12:30 UTC by Anton Vysotsky
Modified: 2019-03-08 17:44 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-03-30 07:22:14


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Vysotsky 2005-05-13 12:30:55 UTC
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: 
./configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)

$ ./configure --prefix=[DEST] --with-as=/usr/sfw/bin/gas  --with-gnu-as
--with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=f95
--with-mpfr=[PATH] --with-gmp=[PATH]

Configure works fine. So libmpfr and libmpfr are founded. After this I tried to
make. I changed real path to MYPATH in log(see below)

$ gmake
[.... skiped....]
gmake[1]: Leaving directory `($MYPATH)/gcc/gcc'
Checking multilib configuration...
multilib.out is unchanged
gmake[1]: Entering directory `($MYPATH)/gcc/sparc-sun-solaris2.10/libgfortran'
gmake  all-am
gmake[2]: Entering directory `($MYPATH)/gcc/sparc-sun-solaris2.10/libgfortran'
/bin/sh ./libtool --mode=compile ($MYPATH)/gcc/gcc/gfortran -B($MYPATH)/gcc/gcc/
-B($DEST)/sparc-sun-solaris2.10/bin/
-B($DEST)/sparc-sun-solaris2.10/lib/ -isystem
($DEST)/sparc-sun-solaris2.10/include -isystem
($DEST)/sparc-sun-solaris2.10/sys-include  -Wall -fno-repack-arrays
-fno-underscoring -c -o
selected_int_kind.lo `test -f 'intrinsics/selected_int_kind.f90' || echo
'($SOURCE)/gcc-4.0.0/libgfortran/'`intrinsics/selected_int_kind.f90
($MYPATH)/gcc/gcc/gfortran -B($MYPATH)/gcc/gcc/ -B($DEST)/sparc-sun-solaris2.10/bin/
-B($DEST)/sparc-sun-solaris2.10/lib/ -isystem
($DEST)/sparc-sun-solaris2.10/include -isystem
($DEST)/sparc-sun-solaris2.10/sys-include -Wall -fno-repack-arrays
-fno-underscoring -c
($SOURCE)/gcc-4.0.0/libgfortran/intrinsics/selected_int_kind.f90  -fPIC -DPIC -o
.libs/selected_int_kind.o
ld.so.1: ($MYPATH)/gcc/gcc/f951: fatal: libgmp.so.3: open failed: No such file
or directory
gfortran: Internal error: Killed (program f951)
Please submit a full bug report.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
gmake[2]: *** [selected_int_kind.lo] Error 1
gmake[2]: Leaving directory `($MYPATH)/gcc/sparc-sun-solaris2.10/libgfortran'
gmake[1]: *** [all] Error 2
gmake[1]: Leaving directory `($MYPATH)/gcc/sparc-sun-solaris2.10/libgfortran'
gmake: *** [all-target-libgfortran] Error 2


THE SAME PROBLEM I HAD ON i386-pc-solaris2.10, i386-pc-solaris2.9.
I think it's a common problem for all solaris platforms.
Comment 1 Andrew Pinski 2005-05-21 14:09:35 UTC
ld.so.1: ($MYPATH)/gcc/gcc/f951: fatal: libgmp.so.3: open failed: No such file
or directory

This means that libgmp is not in your LD_LIBRARY_PATH.
Comment 2 Anton Vysotsky 2005-05-23 09:40:46 UTC
I think if I use ./configure with flags --with-mpfr=[PATH] --with-gmp=[PATH]
libgmp should be automatically added to LD_LIBRARY_PATH for building.
Otherwise it should be mentioned in docs that setting flags --with-[something]
is not enough for building process.
Comment 3 Eric Botcazou 2005-05-31 16:52:32 UTC
Confirmed, but not specific to sparc-sun-solaris2.10.

Comment 4 Francois-Xavier Coudert 2005-11-04 09:11:06 UTC
Patch proposed: http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00244.html
Comment 5 Francois-Xavier Coudert 2006-02-03 20:31:04 UTC
Unfortunately, I don't have time to work on this, so I let it go. Sorry.
Comment 6 Kaveh Ghazi 2006-11-16 00:13:33 UTC
This issue may have more impact now that we're using GMP/MPFR for all languages via the middle-end.  IMHO, the link step for cc1 et al. should prefer the static libs over the shared ones, if they exist.  Not sure if that requires libtool to accomplish portably or not.

BTW, to avoid this, I always build GMP/MPFR with --disabled-shared.
Comment 7 Kaveh Ghazi 2006-11-16 00:41:19 UTC
Another manifestation and (presumably nonportable) workaround:

http://gcc.gnu.org/ml/gcc/2006-11/msg00095.html

Comment 8 Francois-Xavier Coudert 2007-01-09 11:55:59 UTC
Remove the patch keyword, change component to bootstrap as it now isn't Fortran-specific anymore.

From my proposal (one year ago, see comment #4) to have the build machinery adjust LD_LIBRARY_PATH (or similar variable), I felt that many GCC developers might object to that. But still, it should at least be explicitly stated in the documentation (build instructions).
Comment 9 Richard Earnshaw 2007-01-09 15:48:01 UTC
gdb's configure uses AC_LIB_HAVE_LINKFLAGS to test for expat.  This correctly sets up the right link flags so that applications will find the shared library.  Is there any reason we can't use that for GMP/MPFR?
Comment 10 Eric Gallager 2018-03-08 03:35:41 UTC
Possibly related to bug 44425