Re: Questions on crosstool

[Dan Kegel <dank at kegel dot com>]

Bill Garner wrote:
> > > > [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.

glibc needs linux kernel headers so it knows how to make syscalls.

> > > (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 ?

Probably, but that's probably not your problem at the moment.

> 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

Hmm.  I'm not sure about that, but I wouldn't know.

>  b. Replaced short-load-bytes with alignment-traps

or just remove that option, I understand it's the default

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

I did not see any kernel errors in that thread.

>  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