[Qemu-devel] Re: [PATCH 3/3] Workaround --whole-archive on Solaris

[Andreas Färber]

Am 12.12.2009 um 21:57 schrieb Juan Quintela:

> Andreas Färber <address@hidden> wrote:
> > From: Andreas Färber <address@hidden>
> >
> > 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