ts-7000
[Top] [All Lists]

Re: [ts-7000] I built a 2.6 kernel; now what? :)

To:
Subject: Re: [ts-7000] I built a 2.6 kernel; now what? :)
From: Christopher Friedt <>
Date: Fri, 29 Jun 2007 14:40:23 +0200
If you check out the gentoo-embedded mailing list, then you'll see a lot 
of these sort of things.

Main point -> gentoo's crossdev doesn't have any kind of 'success' 
database.

My advice is to go up or down one or two versions. At one point I had 
run a very large regression test, which took several days. It tested 
whether or not certain compilers could be built 'out of the box' with 
crossdev. Here is a small subset of the results:

-> binutils, gcc, kernel-headers, glibc, target
X86_SUCCESSFUL_TOOLCHAINS=(
   "2.15       3.4.6-r2  2.4.33.3     2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.15       3.4.6-r2  2.4.33.3     2.3.6-r5  arm-softfloat-linux-gnu"
   "2.15       3.4.6-r2  2.6.19.2-r2  2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.15       3.4.6-r2  2.6.19.2-r2  2.3.6-r5  arm-softfloat-linux-gnu"
   "2.15       4.1.1-r3  2.4.33.3     2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.15       4.1.1-r3  2.4.33.3     2.3.6-r5  arm-softfloat-linux-gnu"
   "2.15       4.1.1-r3  2.6.19.2-r2  2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.15       4.1.1-r3  2.6.19.2-r2  2.3.6-r5  arm-softfloat-linux-gnu"
   "2.16.1-r3  3.4.6-r2  2.4.33.3     2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.16.1-r3  3.4.6-r2  2.4.33.3     2.3.6-r5  arm-softfloat-linux-gnu"
   "2.16.1-r3  3.4.6-r2  2.6.19.2-r2  2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.16.1-r3  3.4.6-r2  2.6.19.2-r2  2.3.6-r5  arm-softfloat-linux-gnu"
   "2.16.1-r3  4.1.1-r3  2.4.33.3     2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.16.1-r3  4.1.1-r3  2.4.33.3     2.3.6-r5  arm-softfloat-linux-gnu"
   "2.16.1-r3  4.1.1-r3  2.6.19.2-r2  2.3.6-r5  arm-9tdmi-linux-gnu"
   "2.16.1-r3  4.1.1-r3  2.6.19.2-r2  2.3.6-r5  arm-softfloat-linux-gnu"
)

Key -> the word 'softfloat' is used internally in crossdev to signify 
that the target machine will be using soft floating point (obviously 
;-)), but that is the compiler that I used.

Any other 'vendor' keyword is considered invalid (but you can check the 
gentoo cross-compilation guide for details).

Use any of those toolchains mentioned above ( you might want to consider 
replacing '9tdmi' with 'unknown').

~/Chris


Triffid Hunter wrote:
> 
> On Mon, 25 Jun 2007, Jeff Cunningham wrote:
> 
>> No, I didn't have any use flags set. So I tried the following:
>>
>> USE="-* nls glibc-omitfp nptl nptlonly" crossdev -t arm-unknown-linux-gnu
>>
>> And it fails with this build error:
>>
>> gcc version.c -c -std=gnu99 -O2 -Wall -Winline -Wwrite-strings
>> -fmerge-all-constants -fno-strict-
>> aliasing -Wstrict-prototypes      -I../include
>> -I/var/tmp/cross/arm-unknown-linux-gnu/portage/cro
>> ss-arm-unknown-linux-gnu/glibc-2.5-r3/work/build-default-arm-unknown-linux-gnu-linuxthreads/csu
>> -
>> I/var/tmp/cross/arm-unknown-linux-gnu/portage/cross-arm-unknown-linux-gnu/glibc-2.5-r3/work/build
>> -default-arm-unknown-linux-gnu-linuxthreads -I../ports/sysdeps/arm/elf
>> -I../ports/sysdeps/unix/sy
>> sv/linux/arm/linuxthreads -I../ports/sysdeps/unix/sysv/linux/arm
>> -I../ports/sysdeps/unix/sysv/lin
>> ux -I../linuxthreads/sysdeps/unix/sysv/linux
>> -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthre
>> ad -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu
>> -I../sysdeps/unix/common -I../sysdeps/unix/mman
>> -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv
>> -I../linuxthreads/sysdeps/unix/sysv -I../sysd
>> eps/unix/sysv -I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix
>> -I../linuxthreads/sysdeps/unix
>> -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/arm/fpu
>> -I../ports/sysdeps/arm/linuxthrea
>> ds -I../ports/sysdeps/arm -I../sysdeps/wordsize-32
>> -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee7
>> 54/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf
>> -I../sysdeps/generic -I../ports -I../linu
>> xthreads  -I.. -I../libio -I. -nostdinc -isystem
>> /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include -is
>> ystem /usr/arm-unknown-linux-gnu/usr/include -D_LIBC_REENTRANT -include
>> ../include/libc-symbols.h
>>        -DHAVE_INITFINI -o
>> /var/tmp/cross/arm-unknown-linux-gnu/portage/cross-arm-unknown-linux-g
>> nu/glibc-2.5-r3/work/build-default-arm-unknown-linux-gnu-linuxthreads/csu/version.o
>> -MD -MP -MF /
>> var/tmp/cross/arm-unknown-linux-gnu/portage/cross-arm-unknown-linux-gnu/glibc-2.5-r3/work/build-d
>> efault-arm-unknown-linux-gnu-linuxthreads/csu/version.o.dt -MT
>> /var/tmp/cross/arm-unknown-linux-g
>> nu/portage/cross-arm-unknown-linux-gnu/glibc-2.5-r3/work/build-default-arm-unknown-linux-gnu-linu
>> xthreads/csu/version.o
>> ../ports/sysdeps/unix/sysv/linux/arm/sysdep.S: Assembler messages:
>> ../ports/sysdeps/unix/sysv/linux/arm/sysdep.S:32: Error: no such
>> instruction: `rsb r0,r0,$0'
> [snip]
> 
> this is a curious error - either binutils or (first stage) gcc is doing 
> the wrong thing.
> 
>>> I asked google, and it said that your binutils or kernel headers may be
>>> too old - what versions did crossdev choose?
>>>
>> It chose: (cross-arm-unknown-linux-gnu/)
>>    binutils-2.17
>>    linux-headers-2.6.21
>>    gcc-4.1.2
>>    glibc-2.5-r3  (which is failing to build)
> 
> hrm, same as mine.
> 
>>> /usr/local/crossdev -portage # emerge -pv cross-arm-unknown- linux-gnu/ *
>>>
>>> These are the packages that would be merged, in order:
>>>
>>> Calculating dependencies. .. done!
>>> [ebuild R ] cross-arm-unknown- linux-gnu/ binutils- 2.17 USE="-multislot
>>> -multitarget nls -test -vanilla" 0 kB [1]
>>> [ebuild R ] cross-arm-unknown- linux-gnu/ gcc-4.1.2 USE="(-altivec)
>>> -bootstrap -build -d -doc -fortran -gcj -gtk -hardened (-ip28)
>>> (-ip32r10k)
>>> -mudflap (-multilib) -multislot (-n32) (-n64) nls -nocxx -objc -objc++
>>> -objc-gc -test -vanilla" 0 kB [1]
>>> [ebuild R ] cross-arm-unknown- linux-gnu/ glibc-2.5- r3 USE="-build
>>> -debug -glibc-compat20 glibc-omitfp -hardened (-multilib) nls nptl
>>> nptlonly -profile (-selinux)" 0 kB [1]
>>> [ebuild R ] cross-arm-unknown- linux-gnu/ linux-headers- 2.6.21 0 kB [1]
>>>
>>> Total: 4 packages (4 reinstalls), Size of downloads: 0 kB
>>>
>> The above puzzles me. I have the latest crossdev emerged (0.9.18-r2) and
>> it puts crossdev in /usr/sbin, not /usr/local. And there is no option
>> -portage to crossdev, so I can't try the command you used above.
> 
> Your mail client is inserting arbitrary spaces again (the mail I got back 
> from yahoo servers isn't like this, so must be your end) - 
> "/usr/local/crossdev-portage" is the first dir in my PORTDIR_OVERLAY 
> variable, and that's basically emerge -pv */* from within that dir
> 
>> This looks like it might be something you built with your 
>> cross-toolchain after you'd successfully built the cross-toolchain.
> 
> nope, only run crossdev once, and my buildroot doesn't contain gcc, 
> binutils etc. If I built them with my cross toolchain, they'd be created 
> with CBUILD=arm-unknown-linux-gnu which wouldn't work on my host machine.
> 
>> I can do this:
>>
>> achilles rootfs # crossdev -pv -t arm-unknown-linux-gnu
>> -------------------------------------------------------------------------------------------------
>> * Host Portage ARCH:     x86
>> * Target Portage ARCH:   arm
>> * Target System:         arm-unknown-linux-gnu
>> * Stage:                 4 (C/C++ compiler)
>>
>> * binutils:              binutils-[latest]
>> * gcc:                   gcc-[latest]
>> * headers:               linux-headers-[latest]
>> * libc:                  glibc-[latest]
>>
>> * PORTDIR_OVERLAY:       /usr/local/portage
>> * PORT_LOGDIR:           /var/log/portage
>> * PKGDIR:                /usr/portage/packages/cross/arm-unknown-linux-gnu
>> * PORTAGE_TMPDIR:        /var/tmp/cross/arm-unknown-linux-gnu
>>  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~  -  _  -  ~
>> -  _  -  ~  -  _  -  ~  -
>> * Forcing the latest versions of {binutils,gcc}-config/gnuconfig
>> ...                      [ ok ]
>> * Log: /var/log/portage/cross-arm-unknown-linux-gnu-binutils.log
>> * Emerging cross-binutils ...
>>
>> These are the packages that would be merged, in order:
>> Total: 0 packages, Size of downloads: 0
>> kB                                                 [ ok ]
>> * Log: /var/log/portage/cross-arm-unknown-linux-gnu-gcc-stage1.log
>> * Emerging cross-gcc-stage1 ...
>>
>> These are the packages that would be merged, in order:
>>
>>
>> Total: 0 packages, Size of downloads: 0
>> kB                                                 [ ok ]
>> * Log: /var/log/portage/cross-arm-unknown-linux-gnu-linux-headers.log
>> * Emerging cross-linux-headers ...
>>
>> These are the packages that would be merged, in order:
>>
>>
>> Total: 0 packages, Size of downloads: 0
>> kB                                                 [ ok ]
>> * Log: /var/log/portage/cross-arm-unknown-linux-gnu-glibc.log
>> * Emerging cross-glibc ...
>>
>> These are the packages that would be merged, in order:
>>
>> [ebuild  N    ] cross-arm-unknown-linux-gnu/glibc-2.5-r3  USE="-build
>> -debug -glibc-compat20 -glibc-omitfp -hardened (-multilib) -nls -nptl
>> -nptlonly -profile (-selinux)" 0 kB [1]
> 
> here you can see that glibc-omitfp, nls, nptl and nptlonly are turned off 
> which differs from mine.
> 
>> Total: 1 package (1 new), Size of downloads: 0 kB
>> Portage overlays:
>> [1]
>> /usr/local/portage
>> [ ok ]
>> * Log: /var/log/portage/cross-arm-unknown-linux-gnu-gcc-stage2.log
>> * Emerging cross-gcc-stage2 ...
>>
>> These are the packages that would be merged, in order:
>>
>> [ebuild   R   ] cross-arm-unknown-linux-gnu/gcc-4.1.2  USE="doc*
>> fortran* nls (-altivec) -bootstrap -build -d -gcj -gtk -hardened (-ip28)
>> (-ip32r10k) -mudflap (-multilib) -multislot (-n32) (-n64) -nocxx* -objc
>> -objc++ -objc-gc -test -vanilla" 0 kB [1]
> 
> but here, nls is turned on - what's up with your use flags? However, nls 
> shouldn't affect which assembly instructions binutils recognises...
> 
> oh, and "echo cross-arm-unknown-linux-gnu/gcc -fortran >> 
> $ARMROOT/etc/portage/package.use" - I doubt you'll need a cross-fortran 
> compiler ;)
> 
>> Total: 1 package (1 reinstall), Size of downloads: 0 kB
>> Portage overlays:
>> [1] /usr/local/portage
>>
>>
>>> I could quickpkg these for you if you can't get them built yourself,
>>> since
>>> your cpu supports march=athlon- xp.
>>>
>> Thanks, I appreciate your offer - and all your help. it may come to
>> that, but I haven't given up yet on getting a toolchain built.
>>
>> Jeff
> 
> 


 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/ts-7000/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/ts-7000/join
    (Yahoo! ID required)

<*> To change settings via email:
     
    

<*> To unsubscribe from this group, send an email to:
    

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 

<Prev in Thread] Current Thread [Next in Thread>
Admin

Disclaimer: Neither Andrew Taylor nor the University of NSW School of Computer and Engineering take any responsibility for the contents of this archive. It is purely a compilation of material sent by many people to the birding-aus mailing list. It has not been checked for accuracy nor its content verified in any way. If you wish to get material removed from the archive or have other queries about the archive e-mail Andrew Taylor at this address: andrewt@cse.unsw.EDU.AU