qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 04/25] Add hard build dependency on glib


From: Yoder Stuart-B08248
Subject: Re: [Qemu-devel] [PATCH 04/25] Add hard build dependency on glib
Date: Wed, 27 Jul 2011 13:13:44 +0000


> -----Original Message-----
> From: Anthony Liguori [mailto:address@hidden
> Sent: Tuesday, July 26, 2011 5:10 PM
> To: Yoder Stuart-B08248
> Cc: address@hidden
> Subject: Re: [PATCH 04/25] Add hard build dependency on glib
> 
> On 07/26/2011 04:51 PM, Yoder Stuart-B08248 wrote:
> >
> > I am having issues with this in a cross compilation
> > environment.   In Power embedded, almost all our
> > development is using cross toolchains.
> >
> > Neither glib or pkg-config are in our cross build environment and I'm
> > having issues getting them built and installed.
> > Not even sure if pkg-config is even supposed to work in a cross
> > development environment...I'm new to that tool and poking around a bit
> > with google raises some questions.
> 
> You're probably setting up your cross environment incorrectly which, 
> unfortunately, is very
> common.

I got glib to build without too much trouble, however, 'make install' tries to
re-link some stuff and at that point there seems to be a bug somewhere where 
libtool
fails to use the correct CFLAGS and PATH, and thus the make install partially
installs glib before erroring out.

> The proper thing to do is to have GCC use a different system include 
> directory and a different
> prefix.  That will result in a directory where there are gcc binaries with 
> normal names
> installed in ${cross_prefix}/bin
> 
> You need to build and install pkg-config to this prefix too, and then when it 
> comes time to
> actually doing the QEMU configure, you should do something like:
> 
> export PATH=${cross_prefix}/bin:$PATH
> export PKG_CONFIG_PATH=${cross_prefix}/lib/pkg-config:$PKG_CONFIG_PATH
> 
> Many automated cross compiler environment scripts will install specially 
> named versions of gcc
> and binutils in your normal $PATH.  The trouble is, this is a bit of a hack 
> and unless you
> know to make this hack work with other build tools, it all comes tumbling 
> down.

Note-- this is not just a matter of me getting this to work in my
own private build environment, I'm working with a cross toolchain
that gets delivered to our customers that I have little control
over, and I need to get it working in that environment.

Looks like our cross tools have both a specially named version of the tool
(e.g. powerpc-linux-gnu-gcc) and plain (e.g. gcc).  Unfortunately the plain
version of the tools don't seem to be functional (and have never been used as
far as I know).

Will keep fiddling with this...

Stuart




reply via email to

[Prev in Thread] Current Thread [Next in Thread]