[3/3] Workaround --whole-archive on Solaris

From: Andreas Färber <afaerber@opensolaris.org>

On OpenSolaris, neither --whole-archive nor -z allextract
appear to work as expected, causing runtime errors. For example:

qemu: could not open disk image [...]

Fix this by extracting archives and linking their object files individually.

libqemu_common.a contains object files from different subdirectories,
leading to name clashes, e.g., nbd.o vs. block/nbd.o.

Archive a renamed copy of the affected files instead, this avoids
duplicating %.c -> %.o compilation rules. Two dashes are used for the copy
to avoid name clashes between, e.g., block-qcow.c and block/qcow.c.

Contain this behavior to Solaris to avoid speed regressions on Linux.

Signed-off-by: Andreas Färber <afaerber@opensolaris.org>
Cc: Palle Lyckegaard <palle@lyckegaard.dk>
Cc: Ben Taylor <bentaylor.solx86@gmail.com>
---
 Makefile  |   14 ++++++++++++++
 rules.mak |    4 ++++
 2 files changed, 18 insertions(+), 0 deletions(-)

Am 12.12.2009 um 21:57 schrieb Juan Quintela:

> Andreas Färber <andreas.faerber@web.de> wrote:
>> From: Andreas Färber <afaerber@opensolaris.org>
>>
>> On OpenSolaris, neither --whole-archive nor -z allextract
>> appear to work as expected, causing runtime errors. For example:
>>
>> qemu: could not open disk image [...]
>>
>> Fix this by extracting archives and linking their object files  
>> individually.
>>
>> libqemu_common.a contains object files from different subdirectories,
>> leading to name clashes, e.g., nbd.o vs. block/nbd.o.
>>
>> Archive a renamed copy of the affected files instead, this avoids
>> duplicating %.c -> %.o compilation rules. Two dashes are used for  
>> the copy
>> to avoid name clashes between, e.g., block-qcow.c and block/qcow.c.
>>
>> Contain this behavior to Solaris to avoid speed regressions on Linux.
>
> I just wonder.  If we are:
> a- linking all archives (that is the whole point)
> b- some OS's need to unpack the library due to broken ld (or whatever)
>
> why don't we do the right thing?

Maybe because, if we are honest, we have lengthy discussions about  
sticking to ISO/ANSI/POSIX malloc behavior when it affects customers  
on The OS, but silently ignore some "fringe" OS breaking after  
choosing a convenient but non-standard GCC mechanism? ;)

> just put the objects in some directory, and not create the library in
> the 1st place?  It is a static library, not a dynamic one, and we want
> everything in the 1st place.

The trick is knowing which "everything" we want today!

> I think that this is a saner approach that having two ways (well
> currently several ways) of linking all archives.
>
> What do you people think?

Certainly I would prefer having one shared linking mechanism.

The three separate Makefiles (Makefile, Makefile.hw, Makefile.target)  
that govern which objects are to be compiled pose the problem.
In the end, we need some mechanism to get the right set of objects  
into Makefile.target. Previous attempts were
(i) writing object file paths to a file (me not satisfied), or
(ii) printing them from within make (Avi objected), and now
(iii) extracting them from archives (Juan objected for Linux).

Juan, being our Makefile inventor, what about
(iv) moving the assembling of some of the obj-y variables to a shared  
file included by all three Makefiles?
Would that work? If we had, e.g., common-obj-y and libhw{32,64}-obj-y  
accessible in Makefile.target, we could use them for both dependency  
modelling and linking.

Regards,
Andreas

Am 13.12.2009 um 00:07 schrieb Andreas Färber:

>
> Am 12.12.2009 um 21:57 schrieb Juan Quintela:
>
>> Andreas Färber <andreas.faerber@web.de> wrote:
>>> From: Andreas Färber <afaerber@opensolaris.org>
>>>
>>> On OpenSolaris, neither --whole-archive nor -z allextract
>>> appear to work as expected, causing runtime errors. For example:
>>>
>>> qemu: could not open disk image [...]
>>>
>>> Fix this by extracting archives and linking their object files  
>>> individually.
>>>
>>> libqemu_common.a contains object files from different  
>>> subdirectories,
>>> leading to name clashes, e.g., nbd.o vs. block/nbd.o.
>>>
>>> Archive a renamed copy of the affected files instead, this avoids
>>> duplicating %.c -> %.o compilation rules. Two dashes are used for  
>>> the copy
>>> to avoid name clashes between, e.g., block-qcow.c and block/qcow.c.
>>>
>>> Contain this behavior to Solaris to avoid speed regressions on  
>>> Linux.
>>
>> I just wonder.  If we are:
>> a- linking all archives (that is the whole point)
>> b- some OS's need to unpack the library due to broken ld (or  
>> whatever)
>>
>> why don't we do the right thing?

>> just put the objects in some directory, and not create the library in
>> the 1st place?  It is a static library, not a dynamic one, and we  
>> want
>> everything in the 1st place.
>
> The trick is knowing which "everything" we want today!
>
>> I think that this is a saner approach that having two ways (well
>> currently several ways) of linking all archives.
>>
>> What do you people think?

> Juan, being our Makefile inventor, what about
> (iv) moving the assembling of some of the obj-y variables to a  
> shared file included by all three Makefiles?

I've tested some softmmus on OpenSolaris/amd64 and it appears to work!  
Don't have a test environment for all the user emulators though.

Andreas

On 12/13/2009 01:07 AM, Andreas Färber wrote:
>
> Certainly I would prefer having one shared linking mechanism.
>
> The three separate Makefiles (Makefile, Makefile.hw, Makefile.target) 
> that govern which objects are to be compiled pose the problem.
> In the end, we need some mechanism to get the right set of objects 
> into Makefile.target. Previous attempts were
> (i) writing object file paths to a file (me not satisfied), or
> (ii) printing them from within make (Avi objected), and now
> (iii) extracting them from archives (Juan objected for Linux).

Out of the three above, I prefer (ii) despite my objection.

>
> Juan, being our Makefile inventor, what about
> (iv) moving the assembling of some of the obj-y variables to a shared 
> file included by all three Makefiles?
> Would that work? If we had, e.g., common-obj-y and libhw{32,64}-obj-y 
> accessible in Makefile.target, we could use them for both dependency 
> modelling and linking.

But out of the four, I prefer this.

In fact, why not have one large makefile, with different targets called 
for different subdirectories?