|
From: | Andreas Färber |
Subject: | [Qemu-devel] Re: [PATCH 3/3] Workaround --whole-archive on Solaris |
Date: | Sun, 13 Dec 2009 00:07:42 +0100 |
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 avoidsduplicating %.c -> %.o compilation rules. Two dashes are used for the copyto 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
[Prev in Thread] | Current Thread | [Next in Thread] |