[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ltib] Calling Native toolchain as well as target toolchain inmakefi
From: |
Stuart Hughes |
Subject: |
RE: [Ltib] Calling Native toolchain as well as target toolchain inmakefile. |
Date: |
Tue, 23 Jan 2007 14:06:51 +0000 |
Hi Matt,
In general it's best to leave the PATH as set by ltib for spoofing. 95%
of the time this will be your best bet.
As for the enviroment variables, there is no specific document, but the
ltib script itself sets these things up in a single place, take a look
at 'sub setup_env_vars', I think they're mostly self-explanatory.
Regards, Stuart
On Tue, 2007-01-23 at 07:33 -0500, Cross, Matthew wrote:
> Stuart,
>
> Is there a document that describes all the environment variables
> available in the LTIB created build environment?
>
> Ken, One other technique I've noticed some .spec files use is to modify
> the path. When building native tools, it sets the path to
> $UNSPOOF_PATH, and when building target code, it sets it to $SPOOF_PATH.
> For instance, look at the spec file for building Python.
>
> -Matt
>
> --
> Matt Cross
> Senior Lead Software Engineer
> iRobot Corporation
> 63 South Avenue, Burlington, MA 01803
> 781-418-3373 (ph)
> 781-345-0201 (fax)
> address@hidden
> www.irobot.com
>
>
>
> > -----Original Message-----
> > From: address@hidden
> > [mailto:address@hidden On Behalf
> > Of Stuart Hughes
> > Sent: Tuesday, January 23, 2007 3:42 AM
> > To: Ken Gilmer
> > Cc: address@hidden
> > Subject: Re: [Ltib] Calling Native toolchain as well as
> > target toolchain inmakefile.
> >
> > Hi Ken,
> >
> > When building in LTIB the compiler and other tools are
> > spoofed (take a look in the directory /opt/ltib/usr/spoof/
> >
> > The purpose of this is twofold:
> >
> > 1/ Some Makefiles are cross compiler unaware and have
> > hard-wired gcc in their Makefiles. Making this the default
> > causes the least number of patches to cope with plain cross
> > compiler isses.
> >
> > 2/ When you build you need the compiler to pick up your
> > interface headers and libraries from your local environment.
> > The spoofing mechanism does this and effectively puts
> > rootfs/usr/{include,lib} into your compiles. This allows you
> > to have per-instance settings (soft/hard float, uClibc/glibc,
> > powerpc/coldfire etc).
> >
> > In your case you have two options, you can say:
> >
> > HOST_CC=$BUILDCC
> > HOST_CCC=$BUILDCXX
> >
> > and
> > TARGET_CC=gcc
> > TARGET_CCC=g++
> > etc
> >
> > Alternatively you can un-spoof by saying: export
> > PATH=$UNSPOOF_PATH , If you do this you'll need to do any -I
> > rootfs/usr/include, -L rootfs/usr/lib yourself. My advice
> > would be to use option 1 if you can.
> >
> > I'm not sure what the Makefiles look like for this package,
> > but my general advice would be to pass in as little as you need to.
> >
> > Regards, Stuart
> >
> >
> >
> > On Mon, 2007-01-22 at 11:29 -0500, Ken Gilmer wrote:
> > >
> > >
> > > Hello~
> > >
> > >
> > > I'm pretty new to LTIB, and would really appreciate any
> > advice. I am
> > > trying to build the phoneME Advanced JVM for the Freescale
> > mx31 board.
> > > I have found some various issues with the current source tree, with
> > > fixes here
> > >
> > http://forums.java.net/jive/thread.jspa?messageID=196515ޭ
> > 15 . The problem I think I am having is that the phoneME
> > build scripts require compiling some native (host) programs
> > as well as the target binaries. In the phoneME makefile
> > (which is already written with the assumption of cross
> > compilation), I define a path to the native toolchain, as
> > well as to the target toolchain. When I run ./ltib -m
> > scbuild -p phoneME_advance (my package), it goes well for
> > quite a while and then breaks with this:
> > >
> > >
> > > cc ../../build/linux-arm-bug/./obj/zip_util.o
> > > host c++ ../../build/linux-arm-bug/./jcs/compress.o
> > > arm-none-linux-gnueabi-as: unrecognized option `-Qy'
> > > make: *** [../../build/linux-arm-bug/./jcs/compress.o] Error 1
> > > error: Bad exit status from
> > >
> > >
> > > My interpretation of this is that the target toolchain is
> > being called
> > > to generate the native binaries. How can I override this
> > behavior in
> > > LTIB? Is there something I'm missing?
> > >
> > >
> > > Here is the relevant part of my phoneme_advanced.spec file:
> > >
> > >
> > > %Description
> > > %{summary}
> > >
> > >
> > > %Prep
> > > %setup
> > >
> > >
> > > %Build
> > > cd build/linux-arm-bug
> > > make bin
> > >
> > >
> > >
> > >
> > > Here are the environment variables set when the build begins:
> > >
> > >
> > > CVM_HOST = i686-redhat-linux
> > > CVM_TARGET = linux-arm-bug
> > > SHELL = sh -e
> > > HOST_CC = /usr/bin/gcc
> > > HOST_CCC = /usr/bin/g++
> > > ZIP = /usr/bin/zip
> > > FLEX = /opt/freescale/ltib/usr/bin/flex
> > > BISON = /usr/bin/bison
> > > CVM_JAVA = /usr/java/jdk1.5.0_09/bin/java
> > > CVM_JAVAC = /usr/java/jdk1.5.0_09/bin/javac CVM_JAVAH =
> > > /usr/java/jdk1.5.0_09/bin/javah
> > > CVM_JAR = /usr/java/jdk1.5.0_09/bin/jar
> > > TARGET_CC
> > > =
> > >
> > /opt/freescale/usr/local/gcc-4.1.1-glibc-2.4-nptl-2/arm-none-linux-gnu
> > > eabi/bin/arm-none-linux-gnueabi-gcc
> > > TARGET_CCC
> > > =
> > >
> > /opt/freescale/usr/local/gcc-4.1.1-glibc-2.4-nptl-2/arm-none-linux-gnu
> > > eabi/bin/arm-none-linux-gnueabi-g++
> > > TARGET_AS
> > > =
> > >
> > /opt/freescale/usr/local/gcc-4.1.1-glibc-2.4-nptl-2/arm-none-linux-gnu
> > > eabi/bin/arm-none-linux-gnueabi-gcc
> > > TARGET_LD
> > > =
> > >
> > /opt/freescale/usr/local/gcc-4.1.1-glibc-2.4-nptl-2/arm-none-linux-gnu
> > > eabi/bin/arm-none-linux-gnueabi-gcc
> > > TARGET_AR
> > > =
> > >
> > /opt/freescale/usr/local/gcc-4.1.1-glibc-2.4-nptl-2/arm-none-linux-gnu
> > > eabi/bin/arm-none-linux-gnueabi-ar
> > > TARGET_RANLIB
> > > =
> > >
> > /opt/freescale/usr/local/gcc-4.1.1-glibc-2.4-nptl-2/arm-none-linux-gnu
> > > eabi/bin/arm-none-linux-gnueabi-ranlib
> > > LINKFLAGS = -g -Wl,-export-dynamic
> > > LINKLIBS = -lpthread -ldl
> > > ASM_FLAGS = -c -fno-common -traditional
> > > CCCFLAGS = -fno-rtti
> > > CCFLAGS_SPEED = -c -fno-common -Wall -fno-strict-aliasing -O4
> > > CCFLAGS_SPACE = -c -fno-common -Wall -fno-strict-aliasing -O2
> > > CCFLAGS_LOOP = -c -fno-common -Wall -fno-strict-aliasing -O4
> > > CCFLAGS_FDLIB = -c -fno-common -Wall -fno-strict-aliasing -O4
> > > JAVAC_OPTIONS = -g:none -J-Xms32m -J-Xmx128m -encoding iso8859-1
> > > -source 1.4 -target 1.4
> > > CVM_DEFINES = -DCVM_OPTIMIZED -DCVM_DEBUG_STACKTRACES -DNDEBUG
> > > -DCVM_CLASSLOADING -DCVM_SERIALIZATION -DCVM_REFLECT
> > > -DCVM_DYNAMIC_LINKING -DCVM_JIT -DCVM_JIT_REGISTER_LOCALS
> > > -DCVM_TIMESTAMPING -DJ2ME_CLASSLIB=cdc -DTARGET_CPU_FAMILY=arm
> > > -DCVM_JIT_COPY_CCMCODE_TO_CODECACHE -D_GNU_SOURCE -DCVM_IAI_OPT_ALL
> > > -DAAPCS
> > >
> > >
> > > Any help would be greatly appreciated and I would be happy
> > to submit
> > > my package back to the LTIB community once it's working.
> > >
> > >
> > > TIA
> > > ken
> > > _______________________________________________
> > > LTIB home page: http://bitshrine.org
> > >
> > > Ltib mailing list
> > > address@hidden
> > > http://lists.nongnu.org/mailman/listinfo/ltib
> >
> >
> >
> > _______________________________________________
> > LTIB home page: http://bitshrine.org
> >
> > Ltib mailing list
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/ltib
> >
>