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

Wed Apr 27 19:18:05 PDT 2011

Hi Andrew,

thank you for your reply. In fact my environment was not clean, but
most of these issues remain when I corrected my procedure to get clean
environment, please see below.

>2011/4/23 Aleksander Wabik <alex.wabik at gmail.com>:
>> 1) We unset CFLAGS and CXXFLAGS before compiling anything. I'd add unsetting LDFLAGS, as just in my case it made build fail (I had default LDFLAGS=-flto)
>
>You shouldn't have much of any environmental variables set when
>creating the "clfs" user with /dev/null as the skeleton.  Unless your
>host distribution is doing something strange.
>Are you following the book exactly?  If so, what distribution is your host?
>
>Sections 4.2 and 4.3 should get you a user who has as clean of a slate
>as possible.
>
>On Debian 6 x86_64, following section 4.2 gets me a nice empty
>environment, no LD variables are set:
>
>clfs at bigbox:~$ env
>SHELL=/bin/bash
>TERM=xterm
>XDG_SESSION_COOKIE=64bb955c5cc3a95a9a88255b00000aaa-1303726639.85302-297029059
>USER=clfs
>MAIL=/var/mail/clfs
>PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
>PWD=/home/clfs
>LANG=en_US.UTF-8
>SHLVL=1
>HOME=/home/clfs
>LOGNAME=clfs
>DISPLAY=:0.0

Ah, now I see that I've omitted calling env -i in section 4.3 ;/ I am
producing some scripts that will help me to rebuild CLFS automatically
and this was... lost. 

>> 2) Binutils-2.21 build fails:
>> ....
>I think your environment is tainted by the host.  This patch shouldn't
>be needed as those variables shouldn't be set or cause any issues.
>Maybe binutils' configure is setting them, but given a clean
>environment, it should pick the proper settings for those variables.
>This may be similar to your first item.
>
>Again, which distro are you using?  I'd like to check to make sure the
>"clfs" user gets created with a clean environment.
>

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_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.

>> 3) Building kernel with gcc 4.6.0 fails in mips-specific code. The problem is caused by new warnings in gcc 4.6.0:
>
>Can you provide your kernel .config?  I'm not a mips expert kernel configurer.
>I'd like to test this.

I attached the config file. It still fails when I have clean
environment - or in fact, the following environment:

$ env
AS=mips-unknown-linux-uclibc-as
AR=mips-unknown-linux-uclibc-ar
CLFS_HOST=x86_64-cross-linux-gnu
TERM=xterm
CLFS_TARGET=mips-unknown-linux-uclibc
OLDPWD=/media/krypta/clfs-mips/rootfs/sources
LC_ALL=POSIX
CLFS=/media/krypta/clfs-mips/rootfs
PATH=/media/krypta/clfs-mips/rootfs/cross-tools/bin:/bin:/usr/bin:/usr/local/bin
LD=mips-unknown-linux-uclibc-ld
PWD=/media/krypta/clfs-mips/rootfs/sources/linux-2.6.38.3
STRIP=mips-unknown-linux-uclibc-strip
CLFS_ARCH=mips
PS1=\u:\w\$ 
CXX=mips-unknown-linux-uclibc-g++
SHLVL=1
HOME=/home/clfs
CLFS_MIPS_LEVEL=32
CLFS_ABI=32
CLFS_ENDIAN=big
CLFS_FLOAT=hard
RANLIB=mips-unknown-linux-uclibc-ranlib
CC=mips-unknown-linux-uclibc-gcc
READELF=mips-unknown-linux-uclibc-readelf
_=/usr/bin/env

>> 5) A word about ABIs:
>>
>> Can we include eabi? I've seen some number of mips/mipsel/arm toolchains which were using eabi by default; I don't know the details of this ABI and probably some expert should judge if using eabi is reasonable or not.
>
>Does the MIPS EABI work with uClibc on Linux?
>A quick Google search doesn't inspire confidence that it does.

Oh, I was not aware of it. Now I see in uClibc configure options that
EABI is not an option.

>I believe that the thing called EABI is a completely different concept
>for MIPS versus PowerPC versus ARM.  Yes, it's very confusing that
>they all get the same name.

I think that the idea was the same for all those archs - to create ABI
that will improve embedded performance/memory consumption.

>> 6) A word about CFLAGS:
>>
>> we unset CFLAGS, and I guess that the main reason for this is that if CFLAGS contained -march=core2, all target builds will fail; if CFLAGS contained -march=24kc, all host builds (cross toolchain!) would fail.
>
>Yes.
>
>>We can't just set CFLAGS to host-specific ones when compiling for host, and for target-specific ones when building for target, because gcc will build both for host (toolchain) and for target (libgcc, libstdc++).
>
>Why not?  I don't understand what you're getting at.  For host
>programs we're using the host's already existing GCC.  For target
>programs we're using the GCC we built just for our target.  They build
>for different architectures and both will take CFLAGS if passed.

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.

>> What I've found is that gcc can be configured to use different CFLAGS for target build, and different for host build. So I do:
>>
>> # general CFLAGS, should be unset before building gcc!
>> export MIPS_CFLAGS="-O3 -msoft-float -fno-omit-frame-pointer -funwind-tables -march=24kc -mtune=24kc"
>> export X86_CFLAGS="-march=core2 -mtune=core2 -mmmx -msse -msse2 -msse3 -mssse3 -msse4.1 -O3 -fomit-frame-pointer -floop-block -floop-interchange -floop-strip-mine"
>
>In recent versions of the embedded book (since 20110224 book), we set
>GCC up to have the target C flags built in.  In this way, there's no
>worry about setting a huge string of flags when compiling packages or
>with conflicting CFLAGS for host versus target builds.  For those
>packages that need slight changes (like e2fsprogs), we explicitly set
>what $CC should be.
>
>For example, your MIPS_CFLAGS gets the soft-float and arch (which
>specifies tune automatically) taken care of in recent embedded books
>by using the switches passed to GCC when configuring it in both the
>GCC-Static and GCC-Final sections:
>
>--with-abi=${CLFS_ABI} --with-arch=mips${CLFS_MIPS_LEVEL}
>--with-float=${CLFS_FLOAT} --with-endian=${CLFS_ENDIAN}
>
>The choice of O3 versus Os and extra things like no-omit-frame-pointer
>or unwind-tables can easily be added by specifying what $CC should be
>before configuring a package (like we do for e2fsprogs to set Os
>instead of e2fsprog's default O level).  Before typing them out each
>time, take a look through the GCC documentation on optimization
>levels.  O3 gets you quite a lot of optimizations already, potentially
>at the expense of larger file size.  Since we're building for embedded
>(including things like $50 wireless routers), Os is what's used in the
>book for now, fitting into something like 8MB of flash is more
>important than being a few percent quicker to execute.

Yes, I did not mean that -O3 should be used, it was just the example of
my CFLAGS. I'm building for Qemu mips malta to have possibility of
testing my software on different architectures.

best regards,
AW.

-- 
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: kernel-2.6.38.3-config.gz
Type: application/octet-stream
Size: 8536 bytes
Desc: not available
URL: <http://lists.clfs.org/pipermail/clfs-dev-clfs.org/attachments/20110428/50f8162d/attachment-0002.obj>
-------------- 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/50f8162d/attachment-0001.sig>