Hi, sorry it took me so long to reply!
I was doing something that I probably should have realized was a bad
idea right from the start.
While cross-compiling gcc (build=i686,host=arm,target=arm) I had CFLAGS
and CXXFLAGS set - Doh!!
It has nothing(?) to do with --enable-serial (which I guess I
interpreted incorrectly anyway)
Cross-compiling gcc kept failing at libiberty saying "cannot compute
suffix of object files". And I was seeing that libiberty was being
configured for build=i686 _and_ host=i686.
What I didn't realize at first was that libiberty is configured twice
when cross-compiling gcc. The first time for the host machine and the
second time for the build machine. The host libiberty files are located
in gcc-build/libiberty. The build libiberty files are located in
gcc-build/build-i686-pc-linux-gnu/libiberty.
I assumed at first it was only necessary to configure libiberty once -
even when cross compiling gcc. When I saw it configured for the second
time, with build=i686 and host=i686, i thought "hey a secondary stage of
the configure process isn't realizing that i said
host=arm-softfloat-inux-gnu the fist time!"
That's why i assumed --enable-serial-host,build,target would fix my problem.
Just so other people hopefully find this on Google and don't waste as
much of their time as i did, I'm going to append all of my values below.
INCORRECT:
=======================================================================
$ CXXFLAGS="-O2 -mcpu=arm920t" CFLAGS="-O2 -mcpu=arm920t"
../gcc-4.1.2/configure ${MY_ECONF_OPTS} --build=i686-pc-linux-gnu
--target=arm-softfloat-linux-gnu --host=arm-softfloat-linux-gnu
--disable-checking --disable-werror --enable-secureplt
--disable-libunwind-exceptions --disable-nls --with-float=soft
--with-cpu=arm920t
--with-gxx-include-dir=/usr/lib/gcc/arm-softfloat-linux-gnu/4.1.2/include/g++-v4
--enable-languages=c,c++,java
=======================================================================
CORRECT:
=======================================================================
$ ../gcc-4.1.2/configure ${MY_ECONF_OPTS} --build=i686-pc-linux-gnu
--target=arm-softfloat-linux-gnu --host=arm-softfloat-linux-gnu
--disable-checking --disable-werror --enable-secureplt
--disable-libunwind-exceptions --disable-nls --with-float=soft
--with-cpu=arm920t
--with-gxx-include-dir=/usr/lib/gcc/arm-softfloat-linux-gnu/4.1.2/include/g++-v4
--enable-languages=c,c++,java
=======================================================================
For those interested, MY_ECONF_OPTS was from 'man 5 ebuild' (under
econf), and the rest came from /usr/portage/eclass/toolchain.eclass.
I removed --with-system-zlib because it caused a cross-compile error.
The error that I ran into when i mistakenly issued CFLAGS as an
environment variable was:
=======================================================================
$ make
(everything works normally until getting to libiberty [Edit:2nd time])
...
Configuring in build-i686-pc-linux-gnu/libiberty
configure: creating cache ../config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
checking for makeinfo... makeinfo --split-size=5000000
checking for perl... perl
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar
checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib
checking for i686-pc-linux-gnu-gcc... gcc
checking for suffix of object files... configure: error: cannot compute
suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-build-libiberty] Error 1
=======================================================================
With config.log saying:
=======================================================================
configure:2251: checking for suffix of object files
configure:2272: gcc -c -O2 -mcpu=arm920t conftest.c >&5
`-mcpu=' is deprecated. Use `-mtune=' or '-march=' instead.
conftest.c:1: error: bad value (arm920t) for -mtune= switch
configure:2275: $? = 1
=======================================================================
Note to self: do not set a CFLAGS environment variable when
cross-compiling gcc, if CFLAGS is to have _any_ architecture dependent
flags!
It's too bad that gcc doesn't use BUILD_CFLAGS and HOST_CFLAGS. I think
Python does that, no?
At least now I understand why libiberty is compiled twice though. I've
been doing this stuff for years, and I still am finding out really
crucially important things today!
Thanks for the replies - sorry if I've confused anyone.
~/Chris
Mike Frysinger wrote:
On Saturday 01 September 2007, Peter Stuge wrote:
On Thu, Aug 30, 2007 at 06:03:58PM -0400, Mike Frysinger wrote:
is_crosscompile is used to detect whether we're building a
cross-compiler, not whether we're cross-compiling the compiler
Suggest name change to is_crosscompiler
makes sense
The point is though, that even for straight cross-compiles it's
usually more dependent on CHOST being set to a different
architecture than CTARGET.
in the normal case, CTARGET is never set ... however, for all
toolchain based packages, the three tuples (CBUILD CHOST CTARGET)
are made sure to be set to the correct value
What about those --enable-serial-* though? Is there a better
solution for the author's problem?
i really dont have an idea of what the problem is. i build cross-compilers
and cross-compile native compilers and cross-compile cross-compilers and have
yet to hit any problems (which are not fixed in the current tree).
-mike
--
gentoo-embedded@lists.gentoo.org mailing list
