I've tried my hardest to build gcc without resorting to the use of LD_LIBRARY_PATH. I simply can't understand why if LD_FLAGS is set to the path of the mpfr library, the compiler can't use them. My compile bombs out with the well known error: error: cannot compute suffix of object files: cannot compile after trying to build it for a couple of hours. A read of $BUILD_DIRECOTRYsparc-sun-solaris2.10/libgcc/config.log shows the real reason is that the compiler can't find the mpfr library. ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory But I've specified in three ways where to look for this library. 1) Use of -L 2) Use of -R 3) Use of the configure flag --with-mpfr= I've seen others report the same failure (cannot compute suffix of object files) - see for example http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 but it gets closed as 'invalid'. Given gcc finds the library during the initial configure stage, spends two hours compiling (making two copies of xgcc), then to bomb out since it can't find the library seems crazy. So I decided to set LD_LIBRARY_PATH (against my better judgement), but the build would not proceed. However, I expect it will if I set it first, then rebuild. Personally I think there are three things wrong here, that should be fixed, but do doubt the bug will be closed as invalid. 1) Don't expect people to use LD_LIBRARY_PATH 2) Check the location of the libraries in the configure script, so people don't waste two hours building, only to find the library is not found. 3) Respect the option --with-mpfr= 4) Respect LD_FLAGS I expect this will be closed as invalid, so you will still get people (especially on Solaris) finding this odd error. Clearly the configure script found the libraries in a way specified by the options - perhaps the compiler should not forget them a couple of hours later. I note a note by Brian Dessent on bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35693 (reported against 4.3), that the top level configure script should pick this up earlier, not when it comes to run state 1 xgcc for the first time. I can't actually understand why it wont even I will both config.log and sparc-sun-solaris2.10/libgcc/config.log in the hope someone might actually fix this bug, rather than dismiss it.
Created attachment 18081 [details] Top level config.log
Created attachment 18082 [details] sparc-sun-solaris2.10/libgcc/config.log This is the file, which shows it can't find the library, a couple of hours after the configure script finds it. VERY annoying. PLEASE PLEASE fix this. It hits a lot of people - I'm far from the only one.
What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of the built executables to find the mpfr/gmp libraries to not need LD_LIBRARY_PATH set? Note that setting LDFLAGS maybe not what you want (it affects stage1 only AFAIK), you likely want to set BOOT_LDFLAGS. $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++,fortran --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/ --with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib -L /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib
(In reply to comment #3) > What is the LDFLAGS supposed to do? Is it supposed to adjust the run-path of > the built executables to find the mpfr/gmp libraries to not need > LD_LIBRARY_PATH > set? > > Note that setting LDFLAGS maybe not what you want (it affects stage1 only > AFAIK), you likely want to set BOOT_LDFLAGS. > > $ ../gcc-4.4.0/configure CC=/usr/sfw/bin/gcc > --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 > --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld > --without-gnu-ld --enable-languages=c,c++,fortran > --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 > --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/ > --with-libiconv-prefix=/usr/lib/iconv LDFLAGS=-R > /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib > -L > /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib > LD_LIBRARY_PATH should be used as a last resort - not the first resort. But it is surely crazy for the configure script to look for the libraries and header files, then two hours later the build fails since the location of a library, which was previously check for, is now forgotten. Does that not seem a bit illogical? If I've specified the location of the library in a way the configure script accepts, AND specified -L option to the linker, why can't the linker find it?
(In reply to comment #3) > Note that setting LDFLAGS maybe not what you want (it affects stage1 only > AFAIK), you likely want to set BOOT_LDFLAGS. Sorry, forget to comment on that. I'll try that. I would have thought if one set a standard option to the linker like -R, it would have propagated, but I'll try that. It stills seems a bug to me though. This probably should be detected much earlier.
LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are running programs which use shared libraries stored in a "non standard" place.
(In reply to comment #6) > LD_LIBRARY_PATH is for the runtime linker/loader so it is needed as you are > running programs which use shared libraries stored in a "non standard" place. > So is any user who uses the compiler going to need to set LD_LIBRARY_PATH ? That would seem crazy if that is true. I don't need to set LD_LIBRARY_PATH on my Sun to use the gcc from Blastwave, which resides in /opt/csw/bin/gcc or the one which Sun ship which resides in /usr/sfw/bin. It is impossible for me to create a gcc-4.4.0 which links to libraries in locations I chose, without users having to set LD_LIBRARY_PATH? It is not possible to specify the locations of the libraries? I thought options like: --with-mpfr-lib=PATH specify directory for the installed MPFR library were supposed to override the default /usr/local/lib. In some ways, an option like --ignore-usr-local would be nice on LOTS of programs. The trouble with the 'standard' /usr/local is that it tends to accumulate a lot of rubbish.
It looks as though we will have to agree to differ about the LD_LIBRARY_PATH being the right way to do things. But do you not agree that this probably should be found at an earlier stage in the build process? If so, could you at least fix that, so other people don't want so much time over this problem. If you Google for it, you will find there are thousands of references to this.
This is just like building any other program and running the result if you link with a library stored somewhere else. /usr/local/lib not being standard is up to your distro really, it is a standard location according to GCC and should be according to everything else, if it is not then it is a bug with your distro or the runtime loader/linker.
It is semi hard to figure out early on really.
(In reply to comment #3) > Note that setting LDFLAGS maybe not what you want (it affects stage1 only > AFAIK), you likely want to set BOOT_LDFLAGS. FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with 'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file. Hopefully that will avoid the need for setting LD library path. It would be good if the /usr/local thing could be overridden, but sed might come to my rescuse! ../gcc-4.4.0/configure 'CC=/usr/sfw/bin/gcc' \ --prefix=/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32 \ --without-gnu-as \ --without-gnu-ld \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --enable-languages=c,c++,fortran \ --with-mpfr=/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32 \ --with-gmp=/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32 \ --with-libiconv-prefix=/usr/lib/iconv \ BOOT_LDFLAGS='-R /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib -L /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib' \ LDFLAGS='-R /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib -L /usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/lib:/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/lib' It later failed with -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.4.0/gcc -I../../gcc-4.4.0/gcc/. -I../../gcc-4.4.0/gcc/../include -I./../intl -I../../gcc-4.4.0/gcc/../libcpp/include -I/usr/local/gmp-4.3.1-gcc-3.4.3-ABI32/include -I/usr/local/mpfr-2.4.1-gcc-3.4.3-ABI32/include -I../../gcc-4.4.0/gcc/../libdecnumber -I../../gcc-4.4.0/gcc/../libdecnumber/dpd -I../libdecnumber \ -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"4.4.0\" -DDEFAULT_TARGET_MACHINE=\"sparc-sun-solaris2.10\" -DSTANDARD_BINDIR_PREFIX=\"/usr/local/gcc-4.4.0-Sun-linker-and-assembler-ABI32/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB_LINK}" = "X" || test "yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` \ -c ../../gcc-4.4.0/gcc/gcc.c -o gcc.o) In file included from ../../gcc-4.4.0/gcc/gcc.c:73: ./multilib.h:21: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token gmake[3]: *** [gcc.o] Error 1 gmake[3]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32/gcc' gmake[2]: *** [all-stage2-gcc] Error 2 gmake[2]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/kirkby/gcc-4.4.0-built-with-gcc-3.4.3-ABI32' gmake: *** [all] Error 2
> FWIW, BOOT_LDFLAGS. that did not solve it either. I think I'll have a go with > 'sed' and change /usr/local to somewhere else in the gcc-4.4.0.tar file. > Hopefully that will avoid the need for setting LD library path. Don't build the shared version of the libraries if you cannot manage them.
At least with BOOT_LDFLAGS the error is no longer that it cannot find the libraries.
Created attachment 18086 [details] Top level config.log, with libraries in /usr/local/lib This is the top level config.log. I'll post the /sparc-sun-solaris2.10/libgcc/config.log in a minute.
Created attachment 18087 [details] sparc-sun-solaris2.10/libgcc/config.log with mpfr and gmp libraires in /usr/local/lib. As you will note, the first sort of error message is: ld.so.1: cc1: fatal: libmpfr.so.1: open failed: No such file or directory then later down. configure:2630: error: cannot compute suffix of object files: cannot compile
I thought my comments were going to appear before the files were posted, not after it. Anyway, the libraries are in /usr/local/lib, and appear to work, as I can compile and link against them. kirkby@t2:[~] $ /usr/sfw/bin/gcc -L/usr/local/lib -R /usr/local/lib -lgmp -lmpfr hello_world.c kirkby@t2:[~] $ ldd ./a.out libgmp.so.3 => /usr/local/lib/libgmp.so.3 libmpfr.so.1 => /usr/local/lib/libmpfr.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/sfw/lib/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 /platform/SUNW,T5240/lib/libc_psr.so.1 kirkby@t2:[~] But a script I used to try to build gcc #!/bin/sh LDFLAGS='-L/usr/local/lib -R/usr/local/lib' BOOT_LDFLAGS='-L/usr/local/lib -R/usr/local/lib' export LDFLAGS export BOOT_LDFLAGS rm -rf gcc-4.4.0-built-with-gcc-3.4.3-ABI32b mkdir gcc-4.4.0-built-with-gcc-3.4.3-ABI32b cd gcc-4.4.0-built-with-gcc-3.4.3-ABI32b /home/kirkby/gcc-4.4.0/configure 'CC=/usr/sfw/bin/gcc' \ --prefix=/usr/local/gcc-4.4.0-sun-linker \ --without-gnu-as \ --without-gnu-ld \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --enable-languages=c,c++,fortran \ --with-mpfr-lib=/usr/local/lib \ --with-mpfr-include=/usr/local/include \ --with-gmp-include=/usr/local/include \ --with-gmp-lib=/usr/local/lib \ --with-libiconv-prefix=/usr/lib/iconv gmake -j 200 fails, with the logs I just posted.
I just realised that: LDFLAGS='-L/usr/local/lib -R/usr/local/lib' BOOT_LDFLAGS='-L/usr/local/lib -R/usr/local/lib' export LDFLAGS export BOOT_LDFLAGS was probably not the best way to do this. I'm not even sure if it is valid or not, which probably explains it this time.
I have solved this. The key was setting LD_OPTIONS LD_OPTIONS='-L/usr/local/lib -R/usr/local/lib' I suspect that is a Solaris Environment variable, which is useful to the Sun linker I was using, but not to the GNU linker. \\