libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libgcj/1736


From: Nick Hudson
Subject: Re: libgcj/1736
Date: Thu, 15 Mar 2001 15:44:28 +0000

Robert Boehne wrote:
> 
> Nick Hudson wrote:
> > Acutally there is a bigger problem here. If archive_cmds uses LD then
> > there is no correct setting of wl. That is when hardcoding library paths
> > and linking a library with archive_cmds wl should be blank and when
> > linking a binary it should be "-Wl," or whatever.
> >
> > This only happens to work for things like a.out *BSD because libtool
> > recognises these platform's hardcode libary path flag: namely "-R".
> > 
> No, it doesn't matter what you're linking, it matters what tool
> you are using to link.  C++ and Fortran compilers add hidden
> options to the 'real' ld commands they generate, so compilers
> have options to pass an option to the linker, i.e. don't interpret
> the option as a CC option but an ld option.
> IMHO the real problem was that libtool didn't maintain the use of
> $reload_cmd in the multi-language-branch.  MLB Libtool used to
> set LD=$CXX for C++, which is just a kludge.  In any case, the only
> language you can consistently get away with linking with LD is C.
> When you use LD directly you don't need $wl, but you do if you link
> with CXX, F77 or whatever else you need.  But $reload_cmds must use LD
> no matter what the language (as far as I can tell)...

Not sure this is relevant to my problem.

>                                                  ...The MLB libtool
> hasn't quite yet resolved this problem, but resetting wl to nothing
> while using LD, then setting it back before CXX is used should work.
> The evaulations of variables like wl and archive_cmds probably
> still needs some work.

This bit tells me that the problem I'm seeing is a known problem.

Nick
-- 
aka address@hidden, address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]