This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
[Why does crosstool use kernel sources?]For the kernel ABI. Eventually a special set of kernel ABI headers could be used instead.
I am sorry I did not get it. Would appreciate helping me understand more on this.
(Why that particular set of snapshots? Why not gcc-3.4.0-glibc-2.3.2?)
I had first used gcc-3.4.0-glibc-2.3.2.dat from crosstool-0.28-rc31.tar. But since I had problem compiling the kernel with the created toolchain, I was planning to use the crosstools from the "current" link.
What problem are you seeing?
I have detailed the problem before. Before that following are the steps I did to generate the toolchain (apologize it is long):
1. Made a copy of armv5b-softfloat.dat named it as xscale.dat and changed TARGET to TARGET=armv5l-softfloat-linux
Note: Should it have been armv5l-softfloat-linux-gnu ?
2. Made a copy of demo-armv5b-softfloat.sh, named it as demo-xscale.sh. Changed eval to eval `cat xscale.dat gcc-3.4.0-glibc-2.3.2.dat` sh all.sh --notest
Note: I just noticed that gcc-3.4.0-glibc-2.2.5.dat and gcc-3.4.0-glibc-2.1.3.dat has by default 2.4.21 kernel. May be I should not have used glibc-2.3.2 and hence the problems I am seeing compling 2.4.21 kernel with gcc 3.4.0.
3. Modified gcc-3.4.0-glibc-2.3.2.dat's LINUX_DIR to LINUX_DIR=linux-2.4.21
That's fine. BTW gcc-3.4.1 is better than gcc-3.4.0, you should try it once I upload crosstool-0.28-rc32.
4. execute "sh demo-xscale.sh". The toolchain creation was successfull.
5. I have a customized (support for new xscale hardware) 2.4.21 kernel source code. This source code has no problem with gcc 3.2. I set the path to the toolchain's bin directory and compiled. I had three major problems during compile time and did he following changes:
a. Removed the flags -Wa,-mno-fpu
b. Replaced short-load-bytes with alignment-traps
c. include/asm/unistd.h:397: warning: conflicting types for built-in function '_exit'. So I commented out this _exit() function.
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.2-rc2/2.6.2-rc2-mm1/broken-out/gcc-35-exit-fix.patch agrees with you.
After these changes, Compilition of the kernel went fine. However during linking to generate vmlinux, there were several "relocation truncated to fit: R_ARM_PC24" errors.
Those are often actually undefined symbols. Can you post the exact error messages, with some context? You might consider adding -fno-unit-at-a-time to your CFLAGS; it can prevent functions from being optimized out.
My previous thread "pthread.h not found - error while generating toolchain for xscale" details the errors.
Should I have let crosstools not download linux code from kernel.org and instead modify it to use the kernel code I have ?
Sure - just drop a kernel tarball in the download directory, and crosstool will use that instead of downloading. You might also want to use your own kernel .config file instead of the stock (or nonexistent) one crosstool uses. - Dan
-- My technical stuff: http://kegel.com My politics: see http://www.misleader.org for examples of why I'm for regime change
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |