OK, thanks I appreciate all your time and help. I'll try to to solve
the problems of my cross-toolchain any advance I'll report to the list
the solution.
On Dec 27, 2007 10:41 PM, Ken Moffat <[EMAIL PROTECTED]> wrote:
> 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
> _______________________________________________
> Clfs-dev mailing list
> Clfs-dev@lists.cross-lfs.org
> http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
>
--
------------------------------------------------------------------------------
Thanks && Regards
M.Sc. B.Sc. Luís Vitório Cargnini
IEEE Member
Electrical Engineer Faculty @ PUCRS
Ipiranga Avenue, 6681 – Building 30
P.O. Box: 90619-900 – Porto Alegre/RS
Phone: +55 51 3320 3500 extension: 7696
---------------------------------------------------------------------------------
_______________________________________________
Clfs-dev mailing list
Clfs-dev@lists.cross-lfs.org
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
