Re: [lto-plugin, build] Don't link libiberty.a into liblto-plugin.a

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

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