Bug 42756 - Build fails if gold is used as linker and some libraries reside is /usr/local/lib
Summary: Build fails if gold is used as linker and some libraries reside is /usr/local...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
: 86534 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-01-15 11:06 UTC by Artem Anisimov
Modified: 2022-02-26 02:58 UTC (History)
3 users (show)

See Also:
Host: i686-slackware-linux
Target: i686-slackware-linux
Build: i686-slackware-linux
Known to work:
Known to fail:
Last reconfirmed: 2010-01-30 00:09:34


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Artem Anisimov 2010-01-15 11:06:43 UTC
I have PPL and CLooG installed in /usr/local/lib.

The configure script finds these two libraries and generates makefiles that link with them simply by adding -lppl_c -lppl -lcloog. For example,

i686-slackware-linux-gcc  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H  -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o \                                          
          dummy-checksum.o main.o  libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a   ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a  -lcloog  -lppl_c -lppl -lgmpxx -L/home/artem/testing/gcc-build/./gmp/.libs -L/home/artem/testing/gcc-build/./mpfr/.libs -lmpc -lmpfr -lgmp -rdynamic -ldl  -lz -lelf

This works well when GNU ld is used, because it can be taught to look for libraries in /usr/local/bin by editing /etc/ld.so.conf.

However, GNU gold doesn't have such an option and requires that all library paths be passed in the command line explicitly (at least a brief look at options.cc shows no other way to specify additional library paths).

The program can be partially resolved by saying LDFLAGS=-L/usr/local/lib ../gcc/configure ......, which makes stage1 compiler to build successfully. However, building stage2 compiler fails because -L/usr/local/lib does not get added to the command line during compilation of stage2.

I used the following options to configure GCC:

../gcc/configure --prefix=/usr/local/gcc-current --libdir=/usr/local/gcc-current/lib --enable-shared --enable-bootstrap --enable-languages=c,c++ --enable-threads=posix --enable-checking=release --with-system-zlib --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --enable-gold --enable-lto --verbose --with-arch=i686 --target=i686-slackware-linux --build=i686-slackware-linux --host=i686-slackware-linux
Comment 1 Dmitry Gorbachev 2010-01-15 14:45:50 UTC
Try to set LIBRARY_PATH, i.e.:

export LIBRARY_PATH=/usr/local/lib
Comment 2 Dmitry Gorbachev 2010-01-15 14:57:52 UTC
Well, and LD_LIBRARY_PATH=/usr/local/lib , too.
Comment 3 Artem Anisimov 2010-01-15 16:32:12 UTC
(In reply to comment #1)
> Try to set LIBRARY_PATH, i.e.:
> 
> export LIBRARY_PATH=/usr/local/lib
> 

This worked much better ;-) -- stage2 finished successfully, but building libstdc++ in stage3 failed with a bunch of

/usr/bin/ld: error: unsupported symbol binding

Trying to rerun the command to link libstdc++ with -Xlinker --debug=all to see what's going wrong gave no result, because the error message didn't change.
Comment 4 Dmitry Gorbachev 2010-01-16 17:22:16 UTC
This looks like a bug in gold rather then in GCC.

Try the latest development version of gold <http://sourceware.org/binutils/>. If it still fails, please file a bug report with more details at <http://sourceware.org/bugzilla/enter_bug.cgi?product=binutils>.
Comment 5 Artem Anisimov 2010-01-24 12:11:30 UTC
(In reply to comment #4)
> This looks like a bug in gold rather then in GCC.
> 
> Try the latest development version of gold <http://sourceware.org/binutils/>.
> If it still fails, please file a bug report with more details at
> <http://sourceware.org/bugzilla/enter_bug.cgi?product=binutils>.
> 

GCC builds successfully with gold from binutils 2.20.51.

However, the first bug described here still remains -- in my opinion, it's necessary that the build scripts specify all library directories explicitely.
Comment 6 Dmitry Gorbachev 2010-01-29 23:42:23 UTC
> in my opinion, it's necessary that the build scripts
> specify all library directories explicitely.

Then use configure options --with-ppl / --with-ppl-include / --with-ppl-lib, and --with-cloog / --with-cloog-include / --with-cloog-lib.
Comment 7 Artem Anisimov 2010-01-30 05:24:25 UTC
(In reply to comment #6)
> > in my opinion, it's necessary that the build scripts
> > specify all library directories explicitely.
> 
> Then use configure options --with-ppl / --with-ppl-include / --with-ppl-lib,
> and --with-cloog / --with-cloog-include / --with-cloog-lib.
> 

I do not quite agree with you -- these options are supposed to be used when ppl/cloog are installed in a location that only I know of. With /usr/local/lib the situation is different -- the configure script knows about this dir and must also teach the linker about it. Not passing /usr/local/lib in the explicit libraries path means relying on GNU ld's behaviour.
Comment 8 Andrew Pinski 2021-08-26 05:53:53 UTC
*** Bug 86534 has been marked as a duplicate of this bug. ***
Comment 9 Eric Gallager 2022-02-26 02:58:30 UTC
Didn't GCC stop using PPL and CLooG?