[LTO merge][0/15] Description of the final 15 patches

[Ian Lance Taylor]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Mon, 28 Sep 2009, Diego Novillo wrote:
>
>> - libiberty
>> 	I need help with this one.  When the linker plugin is
>> 	enabled (if GCC is configured to use gold), LTO can
>> 	detect LTO objects inside archives via the callbacks it
>> 	gets from the linker.  Since the linker plugin is a
>> 	shared object, and it uses libiberty functions, it needs
>> 	to use a shared libiberty.
>> 
>> 	Currently, we just force --enable-shared on libiberty,
>> 	but I would only want to do that if gold and lto are
>> 	enabled.  We detect gold and lto support in the top
>> 	configure script, but how do I send that down to
>> 	libiberty's configure?
>
> Shared libiberty seems like a bad idea as you then need to deal with 
> soname allocation and changing the soname whenever an ABI-incompatible 
> change is made.  What you actually need is a PIC libiberty to link into 
> the plugin (and avoiding using any global data in libiberty that needs a 
> single copy in any program; hopefully it doesn't have any), not a shared 
> one.

Yes.  Fortunately there is no such thing as a shared libiberty.  If
you configure libiberty with --enable-shared, what you get is a PIC
libiberty (libiberty/pic/libiberty.a) alongside the non-PIC one
(libiberty/libiberty.a).

So all Diego needs to do is pass --enable-shared down to libiberty
when --enable-lto/--enable-gold.  The way to do that is something like
the appended.

Ian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.patch
Type: text/x-diff
Size: 1144 bytes
Desc: shared libiberty
URL: <http://gcc.gnu.org/pipermail/java/attachments/20090929/c0fce376/attachment.bin>