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

[Aleksander Wabik]

Hi,

I hope that the list that I've chosen for this mail is correct.

I'm building CLFS for mips, and during build process I've found some bugs that prevent from successfully finishing this task. I think that most of those bugs are quite generic and would reproduce when building for other architectures too.

I'm not an expert, although I've compiled LFS once, and then CLFS x86-x86_64; so please correct me if I'm wrong somewhere and explain what I'm doing wrong.

So here we go:

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)

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.

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:

arch/mips/mm/tlbex.c: In function 'build_r4000_tlb_refill_handler':
arch/mips/mm/tlbex.c:1155:22: error: variable 'vmalloc_mode' set but not used [-Werror=unused-but-set-variable]
arch/mips/mm/tlbex.c:1154:28: error: variable 'htlb_info' set but not used [-Werror=unused-but-set-variable]
cc1: all warnings being treated as errors

make[2]: *** [arch/mips/mm/tlbex.o] Error 1
make[1]: *** [arch/mips/mm] Error 2
make: *** [arch/mips] Error 2

Treating those warnings as errors is of minor significance, so instead of hacking kernel and fixing probably many places which would warn about set but not used variable, I patched makefile to not contain -Werror flag (attachment linux.mips.gcc-4.6.0-compilation-fix.patch).

4) Further building kernel will succeed, but it will fail later when you copy the newly built kernel:

cp arch/${CLFS_ARCH}/boot/vmlinux ${CLFS}/boot/clfskernel-2.6.38.2
cp: cannot stat `arch/mips/boot/vmlinux': No such file or directory

It turns out that there's no such file. What I see is only ./vmlinux, so just "cp vmlinux ${CLFS}/boot/clfskernel-2.6.38.2" should be fine. Although vmlinux is a no-no for me, and I used make vmlinuz and then I'll copy vmlinuz - the CLFS book could mention 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.

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

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"

# GCC specific CFLAGS
export CFLAGS_FOR_TARGET=$MIPS_CFLAGS 
export CXXFLAGS_FOR_TARGET=$MIPS_CFLAGS
export GOCFLAGS_FOR_TARGET=$CFLAGS_FOR_TARGET
export CFLAGS_FOR_BUILD=$X86_CFLAGS
export CXXFLAGS_FOR_BUILD=$X86_CFLAGS
export GOCFLAGS_FOR_BUILD=$CFLAGS_FOR_BUILD

(note that for my MIPS_CFLAGS I need export CLFS_MIPS_LEVEL=32).

And it works fine. 

Well, that's all. Feel free to comment, I'll be happy to hear what you think. :)

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: binutils-build-paths.patch
Type: text/x-patch
Size: 494 bytes
Desc: not available
URL: <http://lists.clfs.org/pipermail/clfs-dev-clfs.org/attachments/20110423/e230e89a/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux.mips.gcc-4.6.0-compilation-fix.patch
Type: text/x-patch
Size: 521 bytes
Desc: not available
URL: <http://lists.clfs.org/pipermail/clfs-dev-clfs.org/attachments/20110423/e230e89a/attachment-0003.bin>
-------------- 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/20110423/e230e89a/attachment.sig>