Re: libgcj/1736

[Robert Boehne]

Nick Hudson wrote:
> 
> Alexandre Oliva wrote:
> >
> > On Mar  6, 2001, Bryce McKinlay <address@hidden> wrote:
> >
> > > Perhaps it would suffice to simply clear "wl" when entering the
> > > incremental mode, assuming we know the linker will always be called
> > > directly when doing incremental.
> >
> > Yep.  Please try this patch.
> 
> 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".
> 
> Nick
> --
> aka address@hidden, address@hidden

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).  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.

Hope this clarifies,

Robert

-- 
Robert Boehne             Software Engineer
Ricardo Software   Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email:  address@hidden