This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Big endian in combined one-pass build
On Mon, Jan 24, 2011 at 6:42 PM, Ian Lance Taylor <iant@google.com> wrote:
> Drasko DRASKOVIC <drasko.draskovic@gmail.com> writes:
>
>> I am trying to compile GCC 4.5.1 and newlib-1.18.0 in one-pass
>> combined build. I created symlink to newlib directory in gcc
>> directory. Target is arm-elf.
>>
>> I use configuration options --disable-multilib and --with-endian=big.
OK, so I guess that --with-endian=big is useless...
>
> As far as I can see from the source code --with-endian=big is only
> implemented for SH targets, not for ARM targets. ?The documentation is
> unfortunately not really clear on that point. ?Please consider opening a
> bug report at http://gcc.gnu.org/bugzilla/ .
>
>> 3) Do I always have to use armeb-elf instead of arm-elf target when
>> multilib is disabled
>
> Yes, I think you do.
>
> Ian
Hi Ian,
seems that --enable-biendian will force compilation of newlib to BE
mode, and these than can be found under
$GCC_INSTALL_DIR/lib/gcc/arm-elf/4.5.2/be/.
I.e., this "be" directory will start apearing, while before (without
--enable-biendian) added it will be missing.
Newlib do not recognize armeb-elf target, so it has to be patched with :
diff -Naur newlib-1.19.0/newlib/configure.host
chg_newlib-1.19.0/newlib/configure.host
--- newlib-1.19.0/newlib/configure.host 2010-12-02 20:30:46.000000000 +0100
+++ chg_newlib-1.19.0/newlib/configure.host 2011-01-24 17:01:31.000000000 +0100
@@ -96,7 +96,7 @@
arc)
machine_dir=
;;
- arm)
+ arm*)
machine_dir=arm
;;
avr*)
This will allow armeb toolchain to compile, however my software
compiled with this toolchain does not work well.
Note that I also used GCC patch for arm-elf :
diff -Naur gcc-4.5.2/gcc/config/arm/t-arm-elf
chg_gcc-4.5.2/gcc/config/arm/t-arm-elf
--- gcc-4.5.2/gcc/config/arm/t-arm-elf 2009-08-06 16:27:45.000000000 +0200
+++ chg_gcc-4.5.2/gcc/config/arm/t-arm-elf 2011-01-21 18:03:41.000000000 +0100
@@ -49,25 +49,25 @@
# Not quite true. We can support hard-vfp calling in Thumb2, but how do we
# express that here? Also, we really need architecture v5e or later
# (mcrr etc).
-MULTILIB_OPTIONS += mfloat-abi=hard
+MULTILIB_OPTIONS += mfloat-abi=soft
MULTILIB_DIRNAMES += fpu
-MULTILIB_EXCEPTIONS += *mthumb/*mfloat-abi=hard*
+MULTILIB_EXCEPTIONS += *mthumb/*mfloat-abi=soft*
# MULTILIB_OPTIONS += mcpu=ep9312
# MULTILIB_DIRNAMES += ep9312
# MULTILIB_EXCEPTIONS += *mthumb/*mcpu=ep9312*
-#
-# MULTILIB_OPTIONS += mlittle-endian/mbig-endian
-# MULTILIB_DIRNAMES += le be
-# MULTILIB_MATCHES += mbig-endian=mbe mlittle-endian=mle
-#
+
+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*
-#
-# MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork
-# MULTILIB_DIRNAMES += normal interwork
-#
+
+MULTILIB_OPTIONS += mno-thumb-interwork/mthumb-interwork
+MULTILIB_DIRNAMES += normal interwork
+
# MULTILIB_OPTIONS += fno-leading-underscore/fleading-underscore
# MULTILIB_DIRNAMES += elf under
#
which was needed to force soft FPU (otherwise newlib compilation used to break).
BR,
Drasko