[Bug bootstrap/40572] gcc insistance on using LD_LIBRARY_PATH and ignoring LD_FLAGS

david dot kirkby at onetel dot net gcc-bugzilla@gcc.gnu.org
Sat Jun 27 20:57:00 GMT 2009



------- Comment #4 from david dot kirkby at onetel dot net  2009-06-27 20:57 -------
(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? 


-- 


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



More information about the Gcc-bugs mailing list