On Mon, 2011-08-08 at 11:32 -0500, Kumar Gala wrote:
> On Aug 2, 2011, at 8:42 AM, Richard Purdie wrote:
>
> > On Tue, 2011-08-02 at 08:11 -0500, Kumar Gala wrote:
> >> On Aug 1, 2011, at 11:57 AM, Richard Purdie wrote:
> >>
> >>> On Mon, 2011-08-01 at 09:44 -0700, Tom Rini wrote:
> >>>> On 08/01/2011 09:07 AM, Phil Blundell wrote:
> >>>>> On Mon, 2011-08-01 at 09:37 -0500, Kumar Gala wrote:
> >>>>>> Not sure I understand the statement about disambiguate the resulting
> >>>>>> compilers, on PPC where I intend to utilize this we'd have the
> >>>>>> toolchains already named something like:
> >>>>>
> >>>>> The thing about disambiguating was that, if you're going to modify the
> >>>>> configure opts for gcc-cross based (indirectly) on ${MACHINE} you need
> >>>>> to consider what happens if you have a single build directory that's
> >>>>> being used for multiple MACHINEs.
> >>>>
> >>>> What, I think, Kumar is driving at is why are you saying MACHINE when
> >>>> it's a per core tune he's doing. eg, every e5500 would do
> >>>> --with-cpu=e5500
> >>>
> >>> The question is whether we'd like to get to the point of having more
> >>> toolchains or less toolchains. I'd personally like to get to the point
> >>> of less toolchains (e.g. one per arch) rather than more of them. We
> >>> already pass all the appropriate flags around in the ADT/sdk code and in
> >>> our own cross builds, we could easily add those to the default target
> >>> environment too. This would actually make it clearer what is going on to
> >>> the end user too rather than hiding the details into the gcc
> >>> compilation.
> >>>
> >>> So all things considered, I don't think this is the best way to go...
> >>>
> >>
> >> How is this done or exported to the user of an ADT/sdk toolchain?
> >
> > There is a script included in the toolchain tarball which contains the
> > appropriate information. I don't have one handy to check but I suspect
> > Jessica will have. Jessica?
> >
>
> Ping on this script?
I have a build handy so here is the 32 bit toolchain which runs on 64
bit systems for x86:
$ cat environment-setup-i586-poky-linux
export
PATH=/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin:/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/bin/i586-poky-linux:$PATH
export PKG_CONFIG_SYSROOT_DIR=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux
export
PKG_CONFIG_PATH=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux/usr/lib/pkgconfig
export CONFIG_SITE=/opt/poky/1.0+snapshot/site-config-i586-poky-linux
export CC=i586-poky-linux-gcc
export CXX=i586-poky-linux-g++
export GDB=i586-poky-linux-gdb
export TARGET_PREFIX=i586-poky-linux-
export CONFIGURE_FLAGS="--target=i586-poky-linux --host=i586-poky-linux
--build=x86_64-linux
--with-libtool-sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export CFLAGS=" -m32 -march=i586
--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export CXXFLAGS=" -m32 -march=i586
--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export LDFLAGS="--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export CPPFLAGS="--sysroot=/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export
OECORE_NATIVE_SYSROOT="/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux"
export OECORE_TARGET_SYSROOT="/opt/poky/1.0+snapshot/sysroots/i586-poky-linux"
export OECORE_ACLOCAL_OPTS="-I
/opt/poky/1.0+snapshot/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
export POKY_DISTRO_VERSION="1.0+snapshot-20110802"
You can see it captures the correct CFLAGS etc.
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
