From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33937) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjEHM-0006GA-QO for qemu-devel@nongnu.org; Thu, 13 Dec 2012 14:17:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TjEHF-0000C2-4r for qemu-devel@nongnu.org; Thu, 13 Dec 2012 14:17:08 -0500 Received: from db3ehsobe002.messaging.microsoft.com ([213.199.154.140]:26326 helo=db3outboundpool.messaging.microsoft.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TjEHE-0000Br-Sm for qemu-devel@nongnu.org; Thu, 13 Dec 2012 14:17:01 -0500 Date: Thu, 13 Dec 2012 13:16:48 -0600 From: Scott Wood In-Reply-To: <50CA254B.3040608@weilnetz.de> (from sw@weilnetz.de on Thu Dec 13 12:58:19 2012) Message-ID: <1355426208.14046.6@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/13/2012 12:58:19 PM, Stefan Weil wrote: > Am 13.12.2012 16:53, schrieb Scott Wood: >> On 12/13/2012 12:31:14 AM, Stefan Weil wrote: >>> Indeed, --cross-prefixdoes not support absolute path names. >>>=20 >>> I assume that the executables in >>> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/binare =20 >>> without prefix >>> (gcc, ld, ...). >>=20 >> No, they are with prefix, just not in $PATH. I have more than one =20 >> "powerpc-linux-gnu" toolchain and I don't want to mess with my $PATH =20 >> constantly to choose between them. >>=20 >>> Then there must also be the same executables with prefix >>> (powerpc-linux-gnu-gcc, powerpc-linux-gnu-ld, ...). These must be =20 >>> somewhere in PATH. >>=20 >> No. This was never a requirement before -- why now? >>=20 >>> Use --cross-prefix=3Dpowerpc-linux-gnu-(note the "-" at the end). >>> Then pixman would be configured with --host=3Dpowerpc-linux-gnu and =20 >>> should find >>> the compiler. It won't find the compiler powerpc-linux-gcc when its =20 >>> real name is >>> powerpc-linux-gnu-gcc. >>=20 >> No, it's real name is =20 >> /home/scott/fsl/tc/gcc-4.5.55-eglibc-2.11.55/powerpc-linux-gnu/bin/power= pc-linux-gnu-gcc >>=20 >> -Scott >=20 >=20 > That are a lot of "no"s. So let me try to be a bit clearer. >=20 > You said that you forced --host=3Dpowerpc-linux into the pixman =20 > configure command. > That cannot work, because your host prefix is powerpc-linux-gnu, not =20 > powerpc-linux. > No wonder that pixman used the native compiler. It wouldn't have mattered. There is no powerpc-linux-gnu-gcc in the =20 path either. > A cross prefix which starts with an absolute path (like in your =20 > scenario) justs > requires adding `dirname "${cross_prefix}"` to PATH and passing > `basename "${cross_prefix%-}" to the pixman configure. Right... I'm not thrilled at the idea of build scripts messing with =20 $PATH -- normally I deal with autoconf builds by explicitly passing in =20 CC and such (and am much happier when I encounter a project such as =20 QEMU-until-recently that is fine with just a cross prefix rather than a =20 host tuple) -- but the alternative is making the QEMU build scripts =20 aware of every build tool than pixman requires. What I don't want to do is put it in $PATH semi-permanently, in the =20 interactive instance of the shell. > These modifications could be added to QEMU's configure and Makefile > if we really want that. Installing pixman once manually also works > and saves compilation time for repeated builds. That's why I no longer > use internal pixman for any of my cross compilations. Yes, I could manually install it, though then I get to deal with =20 telling the pixman build exactly where to install itself, and repeating =20 the process for each toolchain and multilib-variant thereof. -Scott=