[Clfs-dev] problems cross compiling gcc

[Ken Moffat]

On Thu, Dec 27, 2007 at 04:45:42PM -0200, Luís Vitório Cargnini wrote:
> well before start let me introduce my env variables:
> export CLFS="/opt/arm-linux/arm-linux-gnueabi"
> export CLFS_CROSSTOOLS="/opt/arm-linux/bin"
> export CLFS_HOST="i686-pc-linux-gnu"
> export CLFS_TARGET="arm-linux-gnueabi"
> 
> well my binutils 2.18 compiled but, with different arguments not exactly
> like the book, I used the following:
> AR=ar AS=as ../../sources/binutils-2.18/configure --prefix=/opt/arm-linux
> --target=${CLFS_TARGET}   --enable-shared --host=i686
> 
> I don't know why, but was the only way to it configure and compilate, after
> this I did the glibc-headers install,gcc-static, glibc-arm and now I stoped
> in the gcc-arm (chapter 5.9), I used the default compilation line in the
> book and get the following result after make:
> 
[...]
> checking wctype.h presence... yes
> configure: WARNING: wctype.h: present but cannot be compiled
 These warnings are probably benign, I get a lot of warnings in
toolchain packages (for the trunk book) when the machine doing the
build has a different endianness from the target.
> checking for ld version... 21800
> checking for ld that supports -Wl,--gc-sections... configure: error: Link
> tests are not allowed after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-target-libstdc++-v3] Error 1
> make[1]: Leaving directory
> `/home/lvcargnini/puc/instramed/toolchain/build/gcc-arm'
> make: *** [all] Error 2
> 
 So, the correct version of binutils made no difference.  OK, a
quick hunt at www.google.com/linux for "Link tests are not allowed
after GCC_NO_EXECUTABLES" leads me to believe the test program which
configure was trying to run couldn't find some essential headers.

 Have a look at 'config.log' (in the directory where it failed, or
else the nearest config.log in a parent directory - binutils and gcc
are notorious for scattering config.log files throughout their
trees.  Find the last test which failed, and look for the error
messages.  I'm guessing your headers are not where 'configure' is
looking for them.

 It might, of course, be a different sort of error, it's even
possible that the book could be broken for your architecture.

> 
> according your previous mail :
> >2. I'm not familiar with the sysroot build, and you haven't made it
> easy for me by saying _which_  build of gcc this is.  The final
> options make it look like the compile in "installing system
> software", but what is the '--enable-cross' and why do you need to
> pass '--with-headers' ?
> 
> this is an old parameter to set the path to include directory, just this
> 
> >3. You are installing this compiler into /opt/arm-linux : the
> sysroot book puts the initial compilers into ${CLFS}/cross-tools and
> the final compiler into ${CLFS}/user.  If /opt/arm-linux is the same
> as ${CLFS} you are putting the compiler into the root of the system
> tree.
> 
> take a look on my variables on beginning of message, in true I putting LFS
> inside /opt/arm-linux/arm-linux-gnueabi and cross-tools inside
> /opt/arm-linux (like crosstool, similar to denx too)
> 
 In case you don't know, I'm a guy who hates cross-compiling!  It's
full of its own idiosyncratic problems, and new releases of almost
any package create new problems.  In some cases, it's better than
the alternatives, so I put up with it.  But I don't have a deep
background for knowing how to fix the problems.  I know that
crosstool is well-regarded, I also know that it does things
differently from clfs and when I've been googling for error messages
I've seen all sorts of crosstool problems without any posted
solution.  I know nothing of denx' method for cross-compilation, but
I have a high regard for the man, his company, and their software
products.  BUT, as an ordinary user you cannot go mixing other
methods with the clfs method.  When things break (and they break
often enough anyway in the development books), nobody else is doing
it your way so the chance of anyone recognising the symptoms is
poor.

 If we had hundreds of people participating on this list, you might
have a chance of getting support for problems which seem to be
caused by your doing things differently from the book.  But we
don't, and I get the feeling you are likely to soon find out that
"if it breaks, you get to keep both pieces" when you do things your
own way.

 Problems give you an opportunity to learn - you have all the error
messages, you need to find them and resolve them.  There is nothing
special about the method of how we do things in the clfs book, it's
just what works for us.  So, if you can do it differently, 'More
power to your elbow!' as we say.  But if you can't solve the
problems, or aren't willing to invest the necessary time to try, you
will do better by following the book the first time you try it.
After that, you can make incremental changes to how you build, and
see if htey work.

ĸen
-- 
das eine Mal als Tragödie, das andere Mal als Farce