From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MFlos-0004J6-Dj for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:16:06 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MFlon-0004Iu-13 for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:16:05 -0400 Received: from [199.232.76.173] (port=41579 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MFlom-0004Ir-Tx for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:16:00 -0400 Received: from mx2.redhat.com ([66.187.237.31]:44203) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MFlom-00011e-GR for qemu-devel@nongnu.org; Sun, 14 Jun 2009 05:16:00 -0400 Message-ID: <4A34BFCA.9040403@redhat.com> Date: Sun, 14 Jun 2009 12:15:54 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Avoiding --whole-archive References: <616D744F-F31E-4E96-9A23-1664C78313FD@web.de> <64FD5BFF-581C-4202-97EA-48BC96A2211C@web.de> <4A2258D7.5020002@codemonkey.ws> <03B6CD6A-6CD3-4D60-97BE-8CFABA82F835@web.de> <9E275697-0576-4CD3-AEB2-68734B720FA3@web.de> In-Reply-To: <9E275697-0576-4CD3-AEB2-68734B720FA3@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: QEMU Developers Andreas F=E4rber wrote: >> it seems linking object files works while linking static libraries=20 >> does not. >> >> Architecturally the problem appears to be that the set of objects to=20 >> link is determined in Makefile and Makefile.hw but is unknown to=20 >> Makefile.target, where the problematic linking happens. >> As a workaround, I've written the respective set of $(OBJS) to a file=20 >> when linking and appending them to the LINK command. Except for two=20 >> warnings (../aio.h and ../cache-utils.o linked twice) this works fine=20 >> and makes BeOS boot up again. > > I came up with another workaround myself, that is using Makefile=20 > pseudotargets plus some Makefile magic to fetch the contents of=20 > $(OBJS) from Makefile.target. I then misuse the $(sort ) function to=20 > eliminate duplicates and thus linker warnings. > > Linux/sparc and BeOS/i386 still boot okay despite the reordering. > > Comments?=20 Way too clever, IMO. The danger here is that people will fear to edit=20 the makefiles after this. > Better ideas? > Maybe a little bit better: > > +libqemu_common.a-OBJS: > + @for o in $(OBJS); do echo ../$$o; done > + libqemu_common.objlist: $(OBJS) echo $(sort $(foreach obj, $^, $(shell readlink -f $(obj)))) > $@ > > $(QEMU_PROG): LIBS +=3D $(SDL_LIBS) $(COCOA_LIBS) $(CURSES_LIBS)=20 > $(BRLAPI_LIBS) $(VDE_LIBS) $(CURL_LIBS) > -$(QEMU_PROG): ARLIBS=3D../libqemu_common.a libqemu.a $(HWLIB) > +$(QEMU_PROG): ARLIBS=3Dlibqemu.a > $(QEMU_PROG): $(OBJS) ../libqemu_common.a libqemu.a $(HWLIB) > - $(call LINK,$(OBJS)) > + $(call LINK,$(sort $(OBJS) $(shell $(MAKE) -C ..=20 > --no-print-directory libqemu_common.a-OBJS) $(shell $(MAKE) -C $(dir=20 > $(HWLIB)) --no-print-directory $(notdir $(HWLIB))-OBJS))) > Here, depend on libqemu_common.objlist, and link it by including its=20 contents in the link command line. Oh, we could even make .objlist a linker script, except that's probably=20 platform specific. The real fix is building everything from a single makefile. --=20 error compiling committee.c: too many arguments to function