[Top][All Lists]
[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
- Re: libgcj/1736, Bryce McKinlay, 2001/03/06
- Re: libgcj/1736, Alexandre Oliva, 2001/03/06
- Re: libgcj/1736, Bryce McKinlay, 2001/03/06
- Re: libgcj/1736, Alexandre Oliva, 2001/03/08
- Re: libgcj/1736, Alexandre Oliva, 2001/03/08
- Re: libgcj/1736, Bryce McKinlay, 2001/03/08
- Re: libgcj/1736, Nick Hudson, 2001/03/09
- Re: libgcj/1736, Robert Boehne, 2001/03/09
- Re: libgcj/1736,
Nick Hudson <=
- Re: libgcj/1736, Alexandre Oliva, 2001/03/16
- Re: libgcj/1736, Robert Boehne, 2001/03/17
Re: libgcj/1736, Robert Boehne, 2001/03/06