This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: newbie questions remain regarding crosstool with an arm920t target (arm_920TDI)


On Fri, Oct 17, 2003 at 10:13:32AM -0500, Wolcott, Ken (MED, Compuware) wrote:

>   results of "diff arm9tdmi.dat arm920.dat":
> ***************************************************************************************
> ,4c2,4
> < TARGET=arm-9dtmi-linux-gnu
> < GCC_EXTRA_CONFIG="--with-cpu=arm9tdmi --enable-cxx-flags=-mcpu=arm9tdmi"
> < TARGET_CFLAGS="-O"
> ---
> > TARGET=arm-920t-linux-gnu
> > GCC_EXTRA_CONFIG="--with-cpu=920t --enable-cxx-flags=-mcpu=920t"
> > TARGET_CFLAGS="-O"
> \ No newline at end of file
> ***************************************************************************************

> Excerpt of results from running demo.sh:
> ***************************************************************************************
> ...
> Unknown cpu used with --with-cpu=920t
> Configure in 
> /tuba_local/crosstool/crosstool-0.24/build/arm-920t-linux-gnu/gcc-3.2.3-glibc-2.3.2/build-gcc-
> core/gcc failed, exiting.
> ***************************************************************************************

http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/ARM-Options.html#ARM%20Options

-mcpu=name
    This specifies the name of the target ARM processor. GCC uses this
name to determine what kind of instructions it can emit when generating
assembly code. Permissible names are: arm2, arm250, arm3, arm6, arm60,
arm600, arm610, arm620, arm7, arm7m, arm7d, arm7dm, arm7di, arm7dmi,
arm70, arm700, arm700i, arm710, arm710c, arm7100, arm7500, arm7500fe,
arm7tdmi, arm8, strongarm, strongarm110, strongarm1100, arm8, arm810,
arm9, arm9e, arm920, arm920t, arm940t, arm9tdmi, arm10tdmi, arm1020t,
xscale.

I think the right option must be:
-mcpu=arm920t

>   second question: I had asked earlier about statically linking gcc.  I think 
> I may have misunderstood the problem I need to solve.  I see now a 
> distinction in concept between a gcc cross compiler toolchain which itself is 
> statically linked and the target executeables that a gcc cross compiler 
> toolchain generates which may or may not be statically linked.  Talking with 
> one developer I'm supporting seems to possibly support the need to have both 
> the toolchain and the targets statically linked.  So there's still some 
> unresolved ambiguity both here (the requirements) and in concept (how does 
> one do this?)

I think we got all options needed:

./configure --enable-static --distable-shared	to
						gcc (for libstdc++, java)
						glibc (for libc)

make LDFLAGS=-static				to build a static
						toolchain

eventually it enough to call configure like this:
LDFLAGS=-static ./configure --enable-static --distable-shared

and then 'make' w/o LDFLAGS, but this might not be enough.

hth - Marc

-- 
#!/bin/sh
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]