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 <[email protected]>: >> 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@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
kernel-2.6.38.3-config.gz
Description: Binary data
signature.asc
Description: PGP signature
_______________________________________________ Clfs-dev mailing list [email protected] http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
