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

[Rainer Orth]

Hi Dave,

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

I know, but you can disable that at configure time.  I don't know how to
make that the default for lto-plugin, but suppose it is doable.

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

Indeed, that would be very strange.

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

We'd have to build a convenience library anyway, just like libffi and
boehm-gc are used by libgcj.  I haven't yet looked into how to do this,
though.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University