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

[Andrew Bradford]

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

> 2) Binutils-2.21 build fails:
>
> libtool: link: ar cru .libs/libbfd.a  archive.o archures.o bfd.o bfdio.o bfdwin.o cache.o coffgen.o corefile.o format.o init.o libbfd.o opncls.o reloc.o section.o syms.o targets.o hash.o linker.o srec.o binary.o tekhex.o ihex.o stabs.o stab-syms.o merge.o dwarf2.o simple.o compress.o verilog.o elf32-mips.o elfxx-mips.o elf-vxworks.o elf32.o elf.o elflink.o elf-attrs.o elf-strtab.o elf-eh-frame.o dwarf1.o ecofflink.o coff-mips.o ecoff.o elfn32-mips.o elf64-mips.o elf64.o elf64-gen.o elf32-gen.o cpu-mips.o archive64.o
> 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
>
> I've produced a patch, that should be applied after make configure-host, but before make (attachment binutils-build-paths.patch), and it's just unsetting env variables HOST_LIB_PATH_bfd and HOST_LIB_PATH_opcodes. But these variables _are_ there for some reason! It's unclear to me what they do, and I'm not sure what implications of this patch will be, beside that the build succeeds.

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.

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

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

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.

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

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

For some good info on GCC, Network Theory has a really good book
online.  Link to quick overview of optimizations:
http://www.network-theory.co.uk/docs/gccintro/gccintro_49.html

Right now, to keep things simple, we just use mips${CLFS_MIPS_LEVEL}
as the arch.  There are quite a few others that might be better suited
to different processors, but that gets more complicated (see ARM
embedded book ;) ).  GCC documentation:
http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/MIPS-Options.html

-Andrew