Re: doc: clarification of convenience archi and --preserve-dup-deps

[Alexandre Oliva]

On Aug 25, 2005, "Gary V. Vaughan" <address@hidden> wrote:

> Hallo Ralf,
> On 25 Aug 2005, at 13:47, Ralf Wildenhues wrote:


>> * Gary V. Vaughan wrote on Thu, Aug 25, 2005 at 01:25:17PM CEST:

>>> There is a wrinkle in the current implementation of convenience
>>> libraries, in that they contain only PIC objects.  It is, therefore,
>>> not  portable to link them into anything other than another
>>> convenience library or a  shared library. (In practice, it might work
>>> in a lot of real life environments depending on how PIC objects
>>> behave
>>> when linked directly into static archives or applications...

>> I did not know that, and in fact I suggested Tom to use this
>> formulation.  Which systems disallows linking PIC objects in static
>> archives?  (Yet another reason to create both non-PIC and PIC
>> convenience archives, if you ask me.)

> You know, I'm not entirely sure -- probably something arcane like
> Ultrix, AIX or OSF.  ISTR it was Alexandre that pointed it out
> originally, maybe he remembers?

Most platforms incur performance penalties for running PIC where
non-PIC would do, but I think MS-Windows DLLs with exports/imports of
data symbols might actually run into problems should you link PIC that
dllexports data symbols along with non-PIC (or even PIC) that
dllimport those symbols.  That said, I haven't kept track of the
recent (and not so recent) developments involving MS-Windows DLLs, so
the issues might very well be gone by now, and perhaps even on this
platform it's now safe to link PIC into executables.  Or perhaps it
always was, and my concerns were unjustified.

Anyhow, creating non-PIC and PIC convenience archives would be a
welcome feature, but it's not as simple as it sounds.  One has to take
care of cases such as platforms that use PIC by default and avoid the
duplication, cases in which individual object files, or convenience
archives, are not available in PIC form (consider object files
compiled with --disable-shared, and convenience archives created with
them), avoiding using such impure PIC archives to create shared
libraries, etc.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   address@hidden, gcc.gnu.org}
Free Software Evangelist  address@hidden, gnu.org}