[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
deplib find algorithm (was: Problem found: libtool/ltmain.sh pulling in
From: |
Ralf Wildenhues |
Subject: |
deplib find algorithm (was: Problem found: libtool/ltmain.sh pulling in wrong stdc++) |
Date: |
Thu, 18 Aug 2005 14:10:19 +0200 |
User-agent: |
Mutt/1.4.1i |
* Graham Leggett wrote on Fri, Aug 05, 2005 at 03:26:30PM CEST:
>
> I have found the reason for libtool linking to the wrong stdc++, the
> problem is that I don't know libtool well enough to propose the "right"
> solution.
> - The variable "lib_search_path" contains the value below:
> This variable takes precedance over the compiler paths in
> "sys_lib_search_path" and the system paths in "shlib_search_path".
>
> What makes things blow up is the "/usr/local/lib" above - this effectively
> means that any libstdc++ installed in /usr/local/lib is going to take
> precedance over the compiler specific libstdc++ that is listed in
> "sys_lib_search_path".
>
> - How did the /usr/local/lib get there in the first place? It was
> specified to libtool as a -L option on the command line below, which in
> turn came from LDFLAGS:
>
> > /bin/bash ../../libtool --tag=CC --mode=link gcc -I.. -I../..
> > -I/usr/local/include/libxml2 -L/usr/local/lib -R/usr/local/lib -lxml2 -lz
> > -lpthread -liconv -lm -lsocket -lnsl -o libmonacoxml++.la -rpath
> > /udd001/hoops/usr/lib version.lo ../rtxsrc/libosysrt++.la
> > ../rtxmlsrc/libosysrtxml++.la eod/libmonacoxmleod++.la -lxml2 -liconv
> > -lnsl -lsocket -lz -lm -lc
>
> - How did -L/usr/local/lib get into LDFLAGS? The libxml2 dependancy did it:
>
> bash-2.03$ /usr/local/bin/xml2-config --libs
> -L/usr/local/lib -R/usr/local/lib -lxml2 -lz -lpthread -liconv -lm
> -lsocket -lnsl
So, one workaround would be: Don't put libstdc++ in a directory full of
shared libs when you want to use more than one libstdc++.
> So - is the solution to reorder the $lib_search_path and the
> $sys_lib_search_path so that sys_lib_search_path is considered first?
>
> Or do we handle postdeps specially to ignore $lib_search_path and consider
> $sys_lib_search_path only for these libraries?
>
> Not sure what the "right" way is to do this.
One solution would be:
Add a new method which allow us to ask the compiler which lib he would
select. Incidentally, this would fix this for multilib installations as
well. (There are still two problems: fixing that for system libs, and
fixing it for user libs. W.r.t the latter, pkgconfig used to be pretty
unusable the last time I checked, which was quite some time ago. So it
might just be fixed now.)
Daniel Reed's patches were rejected because they did not seem general
enough. My comments toward a possible generalization were not commented
upon. Maybe it's time for the people to rethink that.
http://lists.gnu.org/archive/html/libtool-patches/2005-01/msg00182.html
If you need to see code before you can discuss things, then please state
so. I don't look like I only produce hot air, do I? :)
Cheers,
Ralf