On 6 Feb 2011, at 12:51, Andrew Bradford wrote:

On Sat, Feb 5, 2011 at 11:49 PM, Steven Swann <[email protected] <mailto:[email protected]>> wrote:
Hello all,

I'm having a little trouble with my current ARM build in that I can't seem
to get the CFLAGS and BUILD flags set up correctly.

Basically, I'm trying to take the compilation one-step further by ensuring that my final system takes advantages of all the possible features of my ARM core, rather than it being designed for the generic ARM architecture. With
this in mind, the problems seem to stem from having the flags set up
incorrectly.

My process so far and the logic behind it:

When building the cross compile tools I leave the CFLAGS variable empty and use the following build flags '-mabi=aapcs-linux -mfloat-abi=softfp'. I have
chosen the softfp options since the FPU for my processor isn't 100% ieee
compatable.

From here I compile the static compiler, build uClibc with the .config
supplied, with the only change being support for EABI rather than the OABI. I then compile the final compiler and all seems fine. I leave the remaining configuration of uClibc as is; my logic here is that I wish to compile the tool suit with generic processor options so that I can pass the architecture
specific options when compiling the actual target software.

Once I am ready to build the target software I simply add the following
CFLAGS: "-mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfpu=vfp".

The problems then starts when it comes to using the tool suite with these
CFLAGS. At first busybox failed when issuing the make command with:

"  CC      applets/applets.o
applets/applets.c:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP
make[1]: *** [applets/applets.o] Error 1
make: *** [applets_dir] Error 2
"

So I removed the "-mfloat-abi=softfp" build flag and busybox compiles fine.
Is this a bug? Since I haven't selected the use of the hard FLU ABI...


I then start to try and configure e2fsprogs and this fails too with:
"checking for arm-unknown-linux-uclibc-gcc... arm-unknown-linux-uclibc-gcc
-mabi=aapcs-linux -mfloat-abi=softfp -Os
checking whether the C compiler works... no
"

If I then remove both of the build flags from the configure command it
configures fine:
CC="${CC} ${BUILD} -Os" ../configure --prefix=/usr
 --with-root-prefix="" --host=${CLFS_TARGET} --disable-tls
 --disable-debugfs --disable-e2initrd-helper --disable-nls



I have tried a number of options with the building of the toolsuit, I tried adding the target specific options to the uClibc .config but this seemed to make problems worse since I couldn't get busybox to compile using the tools
due to "ld, cannot find -lfloat".

With this in mind I am a little stuck. If somebody could please give me some guidance on this is would be greatly appreciated. If I am going about it the
wrong way then please let me know.

sjs105

Hardware
Target:
Samsung s3c6410,
ARM core: arm1176jzf-s
FPU: VFPv2

.bashrc
set +h
umask 022
ARMCROSS=/mnt/arm-cross
LC_ALL=POSIX
PATH=${ARMCROSS}/cross-tools/bin:/bin:/usr/bin
export ARMCROSS LC_ALL PATH
unset CFLAGS
unset CXXFLAGS
export BUILD="-mabi=aapcs-linux -mfloat-abi=softfp"
export CLFS_HOST="i486-cross-linux-gnu"
export CLFS_TARGET="arm-unknown-linux-uclibc"
export CLFS_ARCH="arm"
export CLFS_ENDIAN="little"
export CC="arm-unknown-linux-uclibc-gcc"
export CXX="arm-unknown-linux-uclibc-g++"
export AR="arm-unknown-linux-uclibc-ar"
export AS="arm-unknown-linux-uclibc-as"
export LD="arm-unknown-linux-uclibc-ld"
export RANLIB="arm-unknown-linux-uclibc-ranlib"
export READELF="arm-unknown-linux-uclibc-readelf"
export STRIP="arm-unknown-linux-uclibc-strip"
export CFLAGS="-mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfpu=vfp "
export CXXFLAGS="-mcpu=arm1176jzf-s -mtune=arm1176jzf-s -mfpu=vfp"


Steven,

I know your pain. I've been grappling with a similar issue over the past week.
Currently, the embedded book is broken for those wanting to build an
EABI (aapcs-linux or aapcs ABI) version of GCC for arm.  I'm working
on fixing it.

Glad it isn't just me then :)


To correctly build a GCC that supports the EABI, you need to set your
CLFS_TARGET triplet to be "arm-unknown-linux-uclibcgnueabi".  Then,
when you build GCC (both static and final), pass the
"--with-abi=aapcs-linux" switch in addition to the other switches
passed.  If you'd like a soft-float only GCC, add the switch
"--with-float=soft" as well (but if you want to use vfp, you may want
to use "--with-float=softfp" which will enable hard floating point
code that falls back on soft if hard isn't available, see Debian wiki
[http://wiki.debian.org/ArmHardFloatPort] for some good info on these
choices).

That is probably where I'm going wrong. I read somewhere when I first started out about the slight change to the target triplet, but assumed that this OS flag only served as a pointer to the target system OS type and was not of any great significance to the build process... What is it they say
about assumption being the mother of all ...

I also had a look at the debian site when first allocating the ABI type. My problem here is that my FPU isn't 100% ieee compatable so I must use either the 'soft' or 'softfp' switch. I have also found that there is no specific ABI for my FPU since it is 'VFPv2', gcc docs only show
'VFP' or 'VFPv3'.

Then, when configuring uClibc, do a "make menuconfig" before the "make
oldconfig" and switch it from OABI to EABI (like it sounds like you're
already doing).

Doing exactly that.


When you build packages, then you can use your CFLAGS and CXXFLAGS and
they should work as you expect, optimizing for your particular variant
of arm chip.

I am currently in the process of rebuilding my toolsuite with the above amendments to the build options, all seems to be going well ATM. Once I start compiling the system software I'll report my progress.

I've added some info to trac ticket 620
[http://trac.cross-lfs.org/ticket/620] and 749
[http://trac.cross-lfs.org/ticket/749] reflecting these things.
Regards,
Andrew
_______________________________________________
Clfs-support mailing list
[email protected] <mailto:[email protected]>
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org
Perfect :) Cheers for your help

sjs205
_______________________________________________
Clfs-support mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-support-cross-lfs.org

Reply via email to