From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:37790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiwz7-0001cl-IU for qemu-devel@nongnu.org; Wed, 12 Dec 2012 19:49:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tiwz4-0000np-RH for qemu-devel@nongnu.org; Wed, 12 Dec 2012 19:49:09 -0500 Received: from va3ehsobe010.messaging.microsoft.com ([216.32.180.30]:19106 helo=va3outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tiwz4-0000nR-Ne for qemu-devel@nongnu.org; Wed, 12 Dec 2012 19:49:06 -0500 Date: Wed, 12 Dec 2012 18:48:59 -0600 From: Scott Wood In-Reply-To: <50C82854.60602@weilnetz.de> (from sw@weilnetz.de on Wed Dec 12 00:46:44 2012) Message-ID: <1355359739.28445.22@snotra> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; delsp=Yes; format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [RFC PATCH] Allow building without graphics support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Anthony Liguori , qemu-devel@nongnu.org, Gerd Hoffmann On 12/12/2012 12:46:44 AM, Stefan Weil wrote: > Am 12.12.2012 04:18, schrieb Scott Wood: >> QEMU is sometimes used in embedded contexts, where graphical support >> is unnecessary. The ability to turn off graphics support not only >> saves some space, but it eliminates the dependency on pixman. >>=20 >> Signed-off-by: Scott Wood >> --- >> There are undoubtedly some rough edges that need to be cleaned up and >> other parts of graphics code that could be compiled out -- this is =20 >> mainly >> meant to see what people think of the concept. >>=20 >> My immediate motivation was that the QEMU-supplied pixman was being a >> pain to cross compile (especially without hacking up the generated =20 >> QEMU >> makefiles to pass additional things to pixman's configure), and in >> general it would be nice to not have to carry around graphical =20 >> baggage >> when running on hardware that doesn't even have a display (so I was =20 >> more >> inclined to do this than to spend effort fixing the pixman build). >=20 > Hi, >=20 > cross compilation works for me with the internal pixman. > Here is an example which I use to compile Windows 64 bit > executables on Debian: >=20 > ./configure' '--cross-prefix=3Damd64-mingw32msvc-' >=20 > Are there still problems with cross compilation in latest QEMU? It doesn't seem to like my --cross-prefix being a full path rather than =20 being a recognized target pattern: checking host system type... Invalid configuration =20 `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc= -linux-gnu': =20 machine =20 `/home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc= ' =20 not recognized configure: error: /bin/bash /home/scott/fsl/git/qemu/pixman/config.sub =20 /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/powerpc-= linux-gnu =20 failed make: *** [pixman/Makefile] Error 1 When I forced --host=3Dpowerpc-linux into the pixman configure command in =20 QEMU's generated Makefile, it got past that, but it built everything =20 with the native compiler: checking build system type... x86_64-unknown-linux-gnu checking host system type... powerpc-unknown-linux-gnu checking for powerpc-linux-gcc... no checking for gcc... gcc Looking a bit more closely, it seems that it's the QEMU rather than =20 pixman's autoconf that is making the bad assumption about the format of =20 --cross-prefix (I really wasn't up for wading in autoconf). Running =20 basename on cross-prefix and explicitly supplying CC and such to pixman =20 would help, though there still should be a way to pass in an explicit =20 host tuple if you have an unusually-named toolchain. -Scott=