This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [LTO merge][0/15] Description of the final 15 patches
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Diego Novillo <dnovillo at google dot com>
- Cc: gcc at gcc dot gnu dot org, java at gcc dot gnu dot org, Fortran List <fortran at gcc dot gnu dot org>
- Date: Tue, 29 Sep 2009 01:36:35 +0000 (UTC)
- Subject: Re: [LTO merge][0/15] Description of the final 15 patches
- References: <b798aad50909281758s1bfe5a16pabc674b8a8d42fcc@mail.gmail.com>
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.
(You also need to make sure this doesn't affect what is built for the
target, only for the host.)
--
Joseph S. Myers
joseph@codesourcery.com