[Clfs-dev] Improvement suggestion for Embedded CLFS (for mips)

[Aleksander Wabik]

Hi,

>2011/4/27 Aleksander Wabik <alex.wabik at gmail.com>:
>>>2011/4/23 Aleksander Wabik <alex.wabik at gmail.com>:
>>>> 2) Binutils-2.21 build fails:
>>>> ....
>> Reproduced with the clean env:
>>
>> ar: can't set BFD
>> default target to `x86_64-unknown-linux-gnu': Invalid bfd target
>> make[4]: *** [libbfd.la] Error 1 make[4]: Leaving directory
>> `/media/krypta/clfs-mips/rootfs/sources/binutils-build/bfd' make[3]:
>> *** [all-recursive] Error 1 make[3]: Leaving directory
>> `/media/krypta/clfs-mips/rootfs/sources/binutils-build/bfd' make[2]:
>> *** [all] Error 2 make[2]: Leaving directory
>> `/media/krypta/clfs-mips/rootfs/sources/binutils-build/bfd' make[1]:
>> *** [all-bfd] Error 2 make[1]: Leaving directory
>> `/media/krypta/clfs-mips/rootfs/sources/binutils-build' make: *** [all]
>> Error 2
>> Environment:
>>
>> $ env
>> CLFS_HOST=x86_64-cross-linux-gnu
>> TERM=xterm
>> CLFS_TARGET=mips-unknown-linux-uclibc
>> OLDPWD=/media/krypta/clfs-mips/rootfs/sources/binutils-2.21
>> LC_ALL=POSIX
>> CLFS=/media/krypta/clfs-mips/rootfs
>> PATH=/media/krypta/clfs-mips/rootfs/cross-tools/bin:/bin:/usr/bin:/usr/local/bin
>> PWD=/media/krypta/clfs-mips/rootfs/sources/binutils-build
>> CLFS_ARCH=mips
>> PS1=\u:\w\$
>> SHLVL=1
>> HOME=/home/clfs
>> CLFS_MIPS_LEVEL=32
>
>CLFS_MIPS_LEVEL shouldn't be anything other than "1" or "3".  This
>isn't the problem for binutils, but thought I'd mention it.  It could
>affect GCC compilation.

Yes, it should affect only gcc compilation, as only there we're using
this env variable, through switch "--with-arch=mips${CLFS_MIPS_LEVEL}".
As far as I've tested it, this value is then used to set -march command
line switch in gcc for target, and thus I've set it up to 32. The book
mentions that there are other mips levels than 1 or 3, and I'm
targetting 24K processors.

>> CLFS_ABI=32
>> CLFS_ENDIAN=big
>> CLFS_FLOAT=hard
>> _=/usr/bin/env
>>
>> Please notice, that my CLFS_HOST is x86_64-cross-linux-gnu, and my
>> whole system is x86_64-unknown-linux-gnu - that's the one that can't be
>> set as BFD target.
>
>Noted.  The reason I'm confused is because my binutils configures for
>x86_64-unknown-linux-gnu as well, and I don't have any issues building
>binutils (just built cleanly again while writing this email).  My
>CLFS_HOST is x86_64-cross-linux-gnu.  This should be the same to
>yours.
>
>What host distribution are you running?  What version of GCC?
>I'm running Debian 6 x86_64 and GCC 4.4.5 on my host.  If you're
>running Debian or Ubuntu, I have chroots on my host for most recent
>versions of those and I can test this out to see if it can be
>reproduced.

I'm using now CLFS SVN-20090325-x86_64-Multilib, but with my
customizations and updates (sometimes according to CBLFS book,
sometimes not), with gcc 4.6.0 (Configured with: ../gcc-4.6.0/configure
--libdir=/usr/local/lib64 --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-c99 --enable-long-long
--enable-clocale=gnu --disable-libstdcxx-pch --enable-multilib
--enable-languages=c,c++ --enable-gold --enable-ld --enable-lto
--enable-bootstrap --enable-cloog-backend=isl), and binutils 2.21.

I guess that if this problem can't be reproduced on any distro with gcc
4.6.0 and binutils 2.21, I'll have to dig more to find out the cause.
In this case, let's leave this for now.

>>>> 6) A word about CFLAGS:
>> Yes, but the point here is that I want to use platform-specific flags
>> for host and for target. While I can export CFLAGS="-march=core2 ..."
>> before building mpfr, and CFLAGS="-march=24kc ..." before building
>> uClibc, I can't do this before building gcc final, because this is the
>> build both for target (libgcc, libstdc++) and for host (gcc
>> executables). That's why I proposed to use CFLAGS_FOR_HOST,
>> CFLAGS_FOR_TARGET... before building gcc final.
>
>Ah, OK.  I think I understand now.  Yeah, that could be a deficiency.
>From looking through GCC's config.log (from the final build
>configure), it looks like the variables you'd want to set might be
>CFLAGS, CFLAGS_FOR_BUILD, and CFLAGS_FOR_TARGET.  I'm not sure how
>CLFAGS is different than the other two, the build scripts should hold
>the secret.  If you have some insight here, it'd be appreciated.
>
>I can see now what you're getting at.  It would be cool if there was a
>way to set these different CFLAGS.  If you have any proposals, let me
>know or send a patch to the book.

Well, I'm just using CFLAGS_FOR_BUILD and CFLAGS_FOR_TARGET, and it
works for me. 

best regards,

>-Andrew
>_______________________________________________
>Clfs-dev mailing list
>Clfs-dev at lists.cross-lfs.org
>http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org


-- 
Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na
serwerze hkp://keys.gnupg.net

My public key with signature 1024D/E12C5A4C is on the server
hkp://keys.gnupg.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.clfs.org/pipermail/clfs-dev-clfs.org/attachments/20110428/1a47b3b2/attachment-0001.sig>