Re: libtool/ltmain linking wrong (/usr/lib) libstdc++

[Liviu Nicoara]

Ralf Wildenhues wrote:


AFAIK it's not the same issue.  From a glance, it's also distinct from
 which
you pointed to in your other mail.

How do I go about linking with the custom built GCC libstdc++ on the system 
which has a default GCC installed in /usr/lib?


Thanks for all the info you provided.  Please also post output of
  ./libtool --tag=CXX --config


I have attached it as a gzipped archive.



(Unfinished thoughts follow.)

It looks to me we're treating $postdeps in the wrong pass (in the wrong
order).  I'm wondering whether treating GCC libs specially is the least
intrusive fix.  Also, I'm wondering whether we just compute
$compiler_lib_search_path_dir wrongly.


From looking in the output of libtool linking with --debug I saw that 
the libstdc++ library is picked because the only two places where that 
code is looking for it are: /opt/compilers/intel-9.1.042/lib and /usr/lib:


sys_lib_search_path_spec=" /opt/compilers/intel-9.1.042/lib /usr/lib"

IOW, it misses the custom-built gcc 4.1.2 in the path:

$ env | grep -w PATH
PATH=/opt/compilers/intel-9.1.042/bin:/opt/compilers/gcc-4.1.2/bin:/bin:/usr/local/bin:/usr/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/lib/jre1.5.0_04/bin

$ env | grep LD_LIB
LD_LIBRARY_PATH=/opt/compilers/intel-9.1.042/lib:/opt/compilers/gcc-4.1.2/lib:/lib:/usr/local/lib:/usr/lib:/usr/X11R6/lib

I would expect the search variable sys_lib_search_path_spec to contain 
all paths explicitly specified in LD_LIBRARY_PATH. If this is not the 
case there are probably reasons which I do not see right now.


Thanks,
Liviu


libtool.config.gz
Description: application/gzip
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: On Windows, $old_archive_cmds uses `lib' to create static archives.

[Ralf Wildenhues]

* Benoit Sigoure wrote on Mon, Apr 23, 2007 at 08:03:53AM CEST:
> Quoting Ralf Wildenhues <[EMAIL PROTECTED]>:
>> * Benoit Sigoure wrote on Sun, Apr 22, 2007 at 07:42:24PM CEST:
>>>
> But in the end, what's the point of doing this since there is no plan to 
> provide a real support for MSVC++? (AFAIK)

Please search on the libtool-patches list for Peter Ekberg's patches.
Not sure if this is the latest:

Then came the wgcc patches (also not applied), but they don't target
plain MSVC.

>> Which Libtool version do you use?  Plain or with any patches?
>
> A stock ltmain.sh (GNU libtool) 1.5.23a (1.1220.2.412 2006/10/13 14:13:30)

FWIW, the patches were against CVS HEAD.

>>> I want to do this because I want to link everything with the 
>>> /NODEFAULTLIB flag
[...]
>> I guess we could add some flag here.
>> (Want to suggest a patch? ;-)
>
> Why not, but some people might not want to use this flag, so there has to 
> be a way to let it pass through (maybe with some other flags too).

Yep.

> Are you suggesting that libtool ought to support MSVC++'s flags in its
> tough task of argument filtering?

There are (at least) two ways to do this:

1) expand some special environment variable 

2) allow through some special flag
  -Wr,$flag_for_archiver

(for aRchiver), could probably be used.  In the simplest case, it'd be
sufficient if the user could override $AR (with a program + options).
I think for most uses that would be sufficient within Peter's patches.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: libtool/ltmain linking wrong (/usr/lib) libstdc++

[Ralf Wildenhues]

Hello Liviu,

* Liviu Nicoara wrote on Mon, Apr 23, 2007 at 04:54:55PM CEST:
> Ralf Wildenhues wrote:
> >
> >Please also post output of
> >  ./libtool --tag=CXX --config
> 
> I have attached it as a gzipped archive.

Was that with --tag=CXX?

> >It looks to me we're treating $postdeps in the wrong pass (in the wrong
> >order).  I'm wondering whether treating GCC libs specially is the least
> >intrusive fix.  Also, I'm wondering whether we just compute
> >$compiler_lib_search_path_dir wrongly.
> 
> From looking in the output of libtool linking with --debug I saw that 
> the libstdc++ library is picked because the only two places where that 
> code is looking for it are: /opt/compilers/intel-9.1.042/lib and /usr/lib:

Yes, it only later picks up the other paths that are set in $postdeps
for the CXX tag, because it parses $postdeps in the wrong order.

> I would expect the search variable sys_lib_search_path_spec to contain 
> all paths explicitly specified in LD_LIBRARY_PATH. If this is not the 
> case there are probably reasons which I do not see right now.

Hmm.  LD_LIBRARY_PATH is not something that is enforced to be equal for
all users of a system.  A library you compile now with some setting for
LD_LIBRARY_PATH may not run for the next user, with her different
setting, nor for you from another shell.

Cheers, andn thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool