This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]

Richard Guenther <> writes:

> Well, we'd then need to re-architect the symbol merging and
> LTO unit read-in to properly honor linking semantics (drop
> a LTO unit from an archive if it doesn't resolve any unresolved
> symbols).  I don't know how easy that will be, but it shouldn't
> be impossible at least.

Yes, as I understand it, it was the need to replicate linking
semantics that led to the gold plugin framework in the first place.
(There is nothing stopping anybody from adding the same plugin
framework to GNU ld, by the way, it's just that nobody has done the
work.)  Of course all the linker semantics can be copied into the
compiler.  But it's moderately complex.

If you go this route, note that different object file formats have
different rules for when to include an object from an archive, so make
the code flexible.  E.g., in BFD, the code to select an object from an
archive is completely different for COFF and for ELF.

The Darwin linker supports a different plugin framework, by the way.
As far as I know it would be possible to adapt lto-plugin for that


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]