[lto-plugin, build] Don't link libiberty.a into liblto-plugin.a
Dave Korn
dave.korn.cygwin@gmail.com
Wed Dec 15 17:09:00 GMT 2010
On 15/12/2010 16:54, Rainer Orth wrote:
> Hi Dave,
>
>> Bad news I'm afraid. It broke the plugin on Windows: it doesn't build a DLL
>> any more, because ...
> [...]
>> Do you actually have any use for the static version of the plugin? If not,
>> and you were just trying to avoid an assertion that won't happen any more, it
>> would be helpful if you could revert your patch until we've had time to figure
>> out a fuller fix.
>
> I can do that, but I still can't see any use for a static plugin
> anywhere (not knowing Windows at all, fortunately :-)
It's not a windows thing, it's just that libtool always builds both a static
and a shared library. There is in fact a potential use for it; libtool
supports pseudo-dlopening on systems that don't actually have shared libraries
by statically linking that archive into the program that wants to use it -
i.e., ld in this case. But I don't know any systems that support LTO but not
shared libs.
>> Ralf, does this mean we need to make a libiberty convenience library somehow?
>
> That has been my suggestion all along, though nobody commented on that
> so far. Manually hacking around what libtool is designed to do doesn't
> seem like the right way to handle this.
Well, what I don't know is whether we have to fully libtoolize libiberty, or
whether perhaps we can just get lto-plugin to build and link in a libtoolized
convenience library, using the existing libiberty .a or .o files.
cheers,
DaveK
More information about the Gcc-patches
mailing list