On Tue, 3 Jan 2006, Ben Elliston wrote:
(Redirected to gcc-help).
if I understand it correctly, then libgcc.a provided in
/home/karel/usr/local/arm-elf1/bin/../lib/gcc/arm-elf/4.0.1/be/libgcc.a
is build with -mhard-float, while my application with -msoft-float.
Question: any idea how to build GCC tool-chain with soft-float's
libgcc.a for big-endian Xscale? -- here I assume I'm right with my
conclusion above, if this is not the case please correct me.
The normal procedure is that the build system will build you both soft
and hard float versions of libgcc and that you choose to use them at
your option with -msoft-float. Why are you copying t-arm-elf files
around? The source files in the tree should be adequate without
modification.
Ben,
I'm not sure, but when looking into t-arm-elf on trunk (don't have
gcc-4_0-branch here) I see that building of little/big endian combination
and also of soft/hard float combination is commented out. My assumption is
that in such configuration gcc builds just hard float little endian
libgcc.a (see below).
The problem is that even when I uncomment those lines:
# MULTILIB_OPTIONS += mlittle-endian/mbig-endian
# MULTILIB_DIRNAMES += le be
# MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle
#
# MULTILIB_OPTIONS += mhard-float/msoft-float
# MULTILIB_DIRNAMES += fpu soft
# MULTILIB_EXCEPTIONS += *mthumb/*mhard-float*
I still get hard-float libgcc for bing-endian even if I specify
-msoft-float while building/linking my own application. My assumption is
that gcc should build little-endian soft-float by default -- since there
are no `le' nor `soft-float' subdirectories created for libgcc.a, but the
problem is that instead of soft-float it is in fact hard-float. I've noted
that while building libgcc which is not placed into `fpu' directory and
which should be soft-float, that gcc build process does not use
-msoft-float switch. So the only hack which I did to get soft-float
libgcc.a is that I added -msoft-float to the LIBGCC_CFLAGS in
gcc/Makefile.
Is this a bug in gcc? Should I bring it back to the gcc devel?
Thanks,
Karel
--
Karel Gardas kgardas@xxxxxxxxxxxxxxxxxx
ObjectSecurity Ltd. http://www.objectsecurity.com
