mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: cliff white <cliffw@osdl.org>
To: Herbert Poetzl <herbert@13thfloor.at>
Cc: wookie@osdl.org, cherry@osdl.org, linux-kernel@vger.kernel.org,
	linux-gcc@vger.kernel.org
Subject: Re: Kernel Cross Compiling
Date: Mon, 16 Feb 2004 13:41:20 -0800	[thread overview]
Message-ID: <20040216134120.3fb6ffaa.cliffw@osdl.org> (raw)
In-Reply-To: <20040214130321.GA8474@MAIL.13thfloor.at>

On Sat, 14 Feb 2004 14:03:22 +0100
Herbert Poetzl <herbert@13thfloor.at> wrote:

> On Sat, Feb 14, 2004 at 12:32:07AM -0800, Timothy D. Witham wrote:
> >  Just to point out that we (OSDL) already do this.
> > 
> > http://www.osdl.org/projects/26lnxstblztn/results/
> > 
> >   We are willing to add more but it is always willing
> > to look at adding more.
> 
> thanks, yes, I knew about that, but the thing is, I would
> like to use this as automated test (well first step of
> an automated test) for linux-vserver[1] development, and 
> for that purpose i386/ia64 and ppc/ppc64 is a good start 
> but not nearly sufficient, we currently 'support' (or at
> least try to ;) the following archs:
> 
>   alpha, i386, ia64, mips/64, hppa/64, ppc/64
>   sparc/64, s390/x, x86_64, uml
> 
> and got an officially assigned syscall number for 
> 
>   i386, s390, sparc/64, sh3/4, x86_64
> 
> but if you are interested in extending this and making
> it available for linux-vserver kernel compile tests
> too, I'm willing to help if I can ...

We're always grateful for help. Our build engine is called
the Patch Lifecycle Manager, ( http://www.osdl.org/plm-cgi/plm )
and the code is always available either from BK 
( bk://developer.osdl.org/plm ) or as a tarball from Sourceforge
( not CVS ) ( http://sourceforge.net/projects/plm )

Basically, the farm here at OSDL auto-builds 
- each release
- a daily BK snapshot ( from kernel.org ) 
- each new tree from a few maintainers ( -mm, -ac, -mjb, -osdl ) 

We do some cross compiles, using Dan Kegel's fine tools. 

Several things you/we could do:
- You could of course use our stuff to run your compilie farm, we're
	always glad to help. :)
- we always need help with the project. Mailing list is plm-devel@lists.sourceforge.net.
- we're planning on expanding the number of arch's we cross-compile for,
	x86_64 and ppc64 are the next two probable targets. We probably
	wouldn't want to add a lot of other archs doing large compiles,
	but if you have a simple target, we can add quite a few.
	( we noticed you are doing a defconfig. We've done separate config files for those
		builds, to reduce time ) 

hope to hear from you
cliffw

	
> 
> TIA,
> Herbert
> 
> > Tim
> > 
> > On Fri, 2004-02-13 at 12:57, Herbert Poetzl wrote:
> > > Hi Folks!
> > > 
> > > I'm currently investigating the requirements/doability
> > > of a kernel cross compiling test bed/setup, able to do
> > > automated kernel builds for different architecture,
> > > just to see if it compiles and later to verify if a 
> > > given patch breaks that compile on any of the tested
> > > archs ...
> > > 
> > > here a short status, and some issues I ran into so far,
> > > some of them with solutions, others without, and some
> > > interesting? observations ...
> > > 
> > > I would be happy if somebody who has done similar, or
> > > knows how to do it properly ;) could comment on that,
> > > and/or point out possible improvements ...
> > > 
> > > TIA,
> > > Herbert
> > > 
> > > 
> > > 1) CROSS COMPILER / TOOLCHAIN
> > > 
> > >    after reading and testing several cross build and
> > >    toolchain building howtos, I decided to do it a little 
> > >    different, because I do not need glibc to compile the 
> > >    kernel ...
> > > 
> > >    the result are two .spec files[1], or the commands 
> > >    used to build an appropriate toolchain ...
> > >    
> > >    for the binutils the required commands are:
> > > 
> > >    	configure  	    	    	    	    	\
> > > 		--disable-nls                           \
> > > 		--prefix=/usr                           \
> > > 		--mandir=/usr/share/man                 \
> > > 		--infodir=/usr/share/info               \
> > > 		--target=${CROSS_ARCH}-linux
> > >    	make
> > >    
> > >    and for the gcc (after the binutils have been
> > >    installed on the host):
> > > 
> > >    	configure  	    	    	    	    	\
> > > 		--enable-languages=c			\
> > >         	--disable-nls                           \
> > > 		--disable-threads			\
> > > 		--disable-shared			\
> > > 		--disable-checking			\
> > >         	--prefix=/usr                           \
> > >         	--mandir=/usr/share/man                 \
> > >         	--infodir=/usr/share/info               \
> > >         	--target=${CROSS_ARCH}-linux
> > >    	make  TARGET_LIBGCC2_CFLAGS='-Dinhibit_libc  \
> > > 		-D__gthr_posix_h'
> > >    
> > >    where ${CROSS_ARCH} is the target architecture you want
> > >    to compile the toochain for, in my case, this where one
> > >    of the following:
> > > 
> > >    	alpha, hppa, hppa64, i386, ia64, m68k, mips, 
> > > 	mips64, ppc, ppc64, s390, sparc, sparc64, x86_64
> > > 
> > >   PROBLEMS HERE:
> > > 
> > >    I decided to use binutils 2.14.90.0.8, and gcc 3.3.2,
> > >    but soon discovered that gcc-3.3.2 will not be able 
> > >    to build a cross compiler for some archs like the
> > >    alpha, ia64, powerpc and even i386 ;) without some
> > >    modifications[2] but with some help, I got all headers
> > >    fixed, except for the ia64, which still doesn't work
> > > 
> > > 
> > > 2) KERNEL CROSS COMPILING
> > > 
> > >    equipped with the cross compiling toolchains for all
> > >    but one of the architectures mentioned above, I wrote
> > >    a little script, which basically does nothing else 
> > >    but compiling a given kernel for all possible archs.
> > > 
> > >    basically this can be accomplished by doing:
> > > 
> > > 	make ARCH=<arch> CROSS_COMPILE=<arch>-linux-
> > > 
> > > 
> > >    the first result was harrowing:
> > > 
> > > 				2.4.25-pre  2.6.2-rc
> > >    ----------------------------------------------------
> > > 	[ARCH alpha/alpha]      succeeded.  succeeded.
> > > 	[ARCH hppa/parisc]      failed.     failed.
> > > 	[ARCH hppa64/parisc]    failed.     failed.
> > > 	[ARCH i386/i386]        succeeded.  succeeded.
> > > 	[ARCH m68k/m68k]        failed.     failed.
> > > 	[ARCH mips/mips]        failed.     failed.
> > > 	[ARCH mips64/mips]      failed.     failed.
> > > 	[ARCH ppc/ppc]          succeeded.  succeeded.
> > > 	[ARCH ppc64/ppc64]      failed.     failed.
> > > 	[ARCH s390/s390]        failed.     failed.
> > > 	[ARCH sparc/sparc]      failed.     succeeded.
> > > 	[ARCH sparc64/sparc]    failed.     failed.
> > > 	[ARCH x86_64/x86_64]    failed.     succeeded.
> > > 
> > >    so only alpha, i386 and ppc did work on the first run.
> > > 
> > >    what I discovered was, that there IS a big difference
> > >    between an empty .config file and a non exististing 
> > >    one, where latter allowed the make oldconfig to work
> > >    similar to the make defaultconfig available on 2.6,
> > >    and added some archs (see [3] for details)
> > > 
> > >   PROBLEMS & SOLUTIONS HERE:
> > > 
> > >    ppc64: 
> > > 	CROSS32_COMPILE=ppc-linux-  
> > > 	is needed to make this work as expected.
> > > 
> > >    hppa/hppa64: 
> > > 	seems not to compile without using a very big
> > > 	patch, which changes a lot inside the kernel
> > > 
> > >    mips/mips64:
> > > 	seem to use the 'obsoleted' -mcpu= option
> > > 	which results in a cc1: error: invalid option 
> > > 	`cpu=<cpu-here>'
> > > 
> > >    m68k:
> > > 	fails with a hundred errors in the includes
> > > 
> > > 
> > > 3) CONCLUSIONS
> > > 
> > >    it seems that recent kernels (2.4 and 2.6) do not support
> > >    most of the architectures they contain without heavy
> > >    patching (haven't tested for arm, sh3/4, ...)
> > > 
> > >    building cross compiler toolchains isn't that often done
> > >    otherwise it would not require such modifications, and
> > >    the documentation would be up to date ...
> > > 
> > >    it seems that with some minor patches and kernel tweaks
> > >    an automated build is in reach, although some archs seem
> > >    to break from one release to the other ...
> > > 
> > >    the non mainline branches, if they exist are some kernel
> > >    versions behind the current mainstream kernel, which 
> > >    might not mean anything ...
> > > 
> > > 
> > > 4) LINKS & REFERENCES
> > > 
> > >    [1]	http://vserver.13thfloor.at/Stuff/Cross/binutils-cross.spec
> > > 	http://vserver.13thfloor.at/Stuff/Cross/gcc-cross.spec
> > > 
> > >    [2]  http://vserver.13thfloor.at/Stuff/Cross/
> > > 		gcc-3.3.2-cross-alpha-fix.diff.bz2
> > > 		gcc-3.3.2-cross-i386-fix.diff.bz2
> > > 		gcc-3.3.2-cross-ia64-fix.diff.bz2
> > > 		gcc-3.3.2-cross-powerpc-fix.diff.bz2
> > > 
> > >    [3]  http://vserver.13thfloor.at/Stuff/Cross/compile.info
> > > 
> > >    ia64:	http://www.gelato.unsw.edu.au/kerncomp/
> > >    mips:	http://www.linux-mips.org/kernel.html
> > >    hppa:	http://www.parisc-linux.org/kernel/index.html
> > >    ppc64:	http://linuxppc64.org/
> > >    	
> > > 
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-gcc" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > -- 
> > Timothy D. Witham - Lab Director - wookie@osdl.org
> > Open Source Development Lab Inc - A non-profit corporation
> > 12725 SW Millikan Way - Suite 400 - Beaverton OR, 97005
> > (503)-626-2455 x11 (office)    (503)-702-2871     (cell)
> > (503)-626-2436     (fax)
> > 
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-gcc" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


-- 
The church is near, but the road is icy.
The bar is far, but i will walk carefully. - Russian proverb

  parent reply	other threads:[~2004-02-16 21:41 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-13 20:57 Herbert Poetzl
2004-02-13 21:31 ` David Mosberger
2004-02-13 21:44   ` Herbert Poetzl
2004-02-14  0:58     ` David Mosberger
2004-02-14  1:08       ` Herbert Poetzl
2004-02-14  2:35         ` Herbert Poetzl
2004-02-14  2:51           ` David Mosberger
2004-02-16 22:50       ` Jim Wilson
2004-02-16  0:03   ` Peter Chubb
2004-02-14  8:32 ` Timothy D. Witham
2004-02-14 13:03   ` Herbert Poetzl
2004-02-14 19:25     ` Timothy D. Witham
2004-02-14 22:08       ` Herbert Poetzl
2004-02-16 21:41     ` cliff white [this message]
2004-02-16 22:10       ` Herbert Poetzl
2004-02-17 13:26 ` Maciej W. Rozycki
     [not found] <20040213205743.GA30245@MAIL.13thfloor.at.suse.lists.linux.kernel>
2004-02-13 21:25 ` Andi Kleen
2004-02-13 21:46   ` Herbert Poetzl
2004-02-13 23:45   ` Herbert Poetzl
2004-02-15 11:16     ` Geert Uytterhoeven
2004-02-15 17:38       ` Herbert Poetzl
2004-02-16 13:51         ` Keith Owens
2004-02-14  3:26 Stephen M. Kenton
2004-02-14 14:21 ` Herbert Poetzl
2004-02-15 23:28   ` Robert Schwebel
2004-02-15 23:59     ` William Lee Irwin III
2004-02-14 21:03 Dan Kegel
2004-02-14 22:07 ` Herbert Poetzl
2004-02-15  3:51   ` Dan Kegel
2004-02-17 21:51 Judith Lebzelter
2004-02-18  7:19 ` Herbert Poetzl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040216134120.3fb6ffaa.cliffw@osdl.org \
    --to=cliffw@osdl.org \
    --cc=cherry@osdl.org \
    --cc=herbert@13thfloor.at \
    --cc=linux-gcc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wookie@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®