Kernel Cross Compiling

Kernel Cross Compiling

[Herbert Poetzl]

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/
   	

Re: Kernel Cross Compiling

[Andi Kleen]

Herbert Poetzl <herbert@13thfloor.at> writes:

> 	[ARCH sparc64/sparc]    failed.     failed.
> 	[ARCH x86_64/x86_64]    failed.     succeeded.

Your test methology must be broken. 2.4.25rc2 cross compiles 
just fine here from i386 to x86_64. 

-Andi

Re: Kernel Cross Compiling

[David Mosberger]

>>>>> On Fri, 13 Feb 2004 21:57:43 +0100, Herbert Poetzl <herbert@13thfloor.at> said:

  Herbert> I got all headers fixed, except for the ia64, which still
  Herbert> doesn't work

Something sounds wrong here. You shouldn't have to patch headers.

A recipe for building ia32->ia64 cross-toolchain on Debian can be
found here:

 http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation

	--david

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Fri, Feb 13, 2004 at 01:31:28PM -0800, David Mosberger wrote:
> >>>>> On Fri, 13 Feb 2004 21:57:43 +0100, Herbert Poetzl <herbert@13thfloor.at> said:
> 
>   Herbert> I got all headers fixed, except for the ia64, which still
>   Herbert> doesn't work
> 
> Something sounds wrong here. You shouldn't have to patch headers.
> 
> A recipe for building ia32->ia64 cross-toolchain on Debian can be
> found here:
> 
>  http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation

that might work with the ia64 libraries and headers,
but it seems to fail, with the headers included in
the gcc tarball, for cross compiling, if you get it
to compile without (g)libc which should not be required
to build the crossgcc and the kernel, I would be very
interested ...

anyway, thanks for the url,
Herbert

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

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Fri, Feb 13, 2004 at 10:25:00PM +0100, Andi Kleen wrote:
> Herbert Poetzl <herbert@13thfloor.at> writes:
> 
> > 	[ARCH sparc64/sparc]    failed.     failed.
> > 	[ARCH x86_64/x86_64]    failed.     succeeded.
> 
> Your test methology must be broken. 2.4.25rc2 cross compiles 
> just fine here from i386 to x86_64. 

might be, but if, where is it broken ...
(if you need any information, let me know)

started a testrun for 2.4.25-rc2 a few minutes
ago, and will make the results as well as the
detailed build logs available when it completes
(takes some time, about 40-60 mins)

TIA,
Herbert

> -Andi

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Fri, Feb 13, 2004 at 10:25:00PM +0100, Andi Kleen wrote:
> Herbert Poetzl <herbert@13thfloor.at> writes:
> 
> > 	[ARCH sparc64/sparc]    failed.     failed.
> > 	[ARCH x86_64/x86_64]    failed.     succeeded.
> 
> Your test methology must be broken. 2.4.25rc2 cross compiles 
> just fine here from i386 to x86_64. 

okay, here is the promised update, a little later
as planned, because I discovered that doing 'make dep'
would be a great idea too (well that isn't necessary
for 2.6.x so it doesn't change those results), but
still some archs give troubles ...

  linux-2.4.25-rc2        config  dep     kernel  modules

  alpha/alpha:            OK      OK      OK      OK
  hppa/parisc:            OK      OK      FAILED  FAILED
  hppa64/parisc:          OK      OK      FAILED  FAILED
  i386/i386:              OK      OK      OK      OK
  m68k/m68k:              OK      OK      OK      OK
  mips/mips:              OK      OK      FAILED  FAILED
  mips64/mips64:          OK      OK      FAILED  FAILED
  ppc/ppc:                OK      OK      OK      OK
  ppc64/ppc64:            OK      FAILED  FAILED  OK
  s390/s390:              OK      OK      OK      OK
  sparc/sparc:            OK      OK      FAILED  FAILED
  sparc64/sparc64:        OK      OK      OK      OK
  x86_64/x86_64:          OK      OK      OK      OK

but hey, it's better than before ...

you can get all the details, what and why? it fails
from the logs:

  http://vserver.13thfloor.at/Stuff/Cross/LOGS-2.4.25-rc2/

any help or hints are appreciated, as it would be great
to get this running ...

TIA,
Herbert

> -Andi

Re: Kernel Cross Compiling

[David Mosberger]

>>>>> On Fri, 13 Feb 2004 22:44:20 +0100, Herbert Poetzl <herbert@13thfloor.at> said:

  >> A recipe for building ia32->ia64 cross-toolchain on Debian can be
  >> found here:

  >> http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation

  Herbert> that might work with the ia64 libraries and headers, but it
  Herbert> seems to fail, with the headers included in the gcc
  Herbert> tarball, for cross compiling, if you get it to compile
  Herbert> without (g)libc which should not be required to build the
  Herbert> crossgcc and the kernel, I would be very interested ...

Ah, I see now what you mean.  I suspect that's a setup that's rarely
tested, so I'm not surprised to see some breakage.

Having said that, I got gcc v3.3.3 20031212 (prerelease) to build with
minor tweaks (see patch below).  I'm no GCC-built-environment expert
and I'm quite certain that the patch isn't totally correct, but all
the unwind-related stuff isn't really needed in your case, because
that code only comes into play for exception-handling and C cleanup
handlers.

The unwind-sjlj.c problem should occur on most other platforms too, so
I don't think that problem is ia64-specific.

	--david

Index: gcc/unwind-sjlj.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind-sjlj.c,v
retrieving revision 1.11.2.2
diff -u -r1.11.2.2 unwind-sjlj.c
--- gcc/unwind-sjlj.c	2 May 2003 21:01:21 -0000	1.11.2.2
+++ gcc/unwind-sjlj.c	14 Feb 2004 00:50:33 -0000
@@ -22,7 +22,9 @@
 #include "tconfig.h"
 #include "tsystem.h"
 #include "unwind.h"
+#ifndef inhibit_libc
 #include "gthr.h"
+#endif
 
 #ifdef __USING_SJLJ_EXCEPTIONS__
 
Index: gcc/unwind.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/unwind.h,v
retrieving revision 1.7.2.6
diff -u -r1.7.2.6 unwind.h
--- gcc/unwind.h	4 Sep 2003 09:39:44 -0000	1.7.2.6
+++ gcc/unwind.h	14 Feb 2004 00:50:33 -0000
@@ -195,7 +195,9 @@
    compatible with the standard ABI for IA-64, we inline these.  */
 
 #ifdef __ia64__
-#include <stdlib.h>
+# ifndef inhibit_libc
+#  include <stdlib.h>
+# endif
 
 static inline _Unwind_Ptr
 _Unwind_GetDataRelBase (struct _Unwind_Context *_C)
Index: gcc/config/ia64/fde-glibc.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/ia64/fde-glibc.c,v
retrieving revision 1.5
diff -u -r1.5 fde-glibc.c
--- gcc/config/ia64/fde-glibc.c	15 Dec 2001 11:46:51 -0000	1.5
+++ gcc/config/ia64/fde-glibc.c	14 Feb 2004 00:50:34 -0000
@@ -31,6 +31,9 @@
 #ifndef _GNU_SOURCE
 #define _GNU_SOURCE
 #endif
+
+#ifndef inhibit_libc
+
 #include "config.h"
 #include <stddef.h>
 #include <stdlib.h>
@@ -162,3 +165,5 @@
 
   return data.ret;
 }
+
+#endif
Index: gcc/config/ia64/linux.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/ia64/linux.h,v
retrieving revision 1.23
diff -u -r1.23 linux.h
--- gcc/config/ia64/linux.h	3 Sep 2002 21:09:54 -0000	1.23
+++ gcc/config/ia64/linux.h	14 Feb 2004 00:50:34 -0000
@@ -58,7 +58,7 @@
 /* Do code reading to identify a signal frame, and set the frame
    state data appropriately.  See unwind-dw2.c for the structs.  */
 
-#ifdef IN_LIBGCC2
+#ifdef x_IN_LIBGCC2
 #include <signal.h>
 #include <sys/ucontext.h>
 

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Fri, Feb 13, 2004 at 04:58:56PM -0800, David Mosberger wrote:
> >>>>> On Fri, 13 Feb 2004 22:44:20 +0100, Herbert Poetzl <herbert@13thfloor.at> said:
> 
>   >> A recipe for building ia32->ia64 cross-toolchain on Debian can be
>   >> found here:
> 
>   >> http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation
> 
>   Herbert> that might work with the ia64 libraries and headers, but it
>   Herbert> seems to fail, with the headers included in the gcc
>   Herbert> tarball, for cross compiling, if you get it to compile
>   Herbert> without (g)libc which should not be required to build the
>   Herbert> crossgcc and the kernel, I would be very interested ...
> 
> Ah, I see now what you mean.  I suspect that's a setup that's rarely
> tested, so I'm not surprised to see some breakage.
> 
> Having said that, I got gcc v3.3.3 20031212 (prerelease) to build with
> minor tweaks (see patch below).  I'm no GCC-built-environment expert
> and I'm quite certain that the patch isn't totally correct, but all
> the unwind-related stuff isn't really needed in your case, because
> that code only comes into play for exception-handling and C cleanup
> handlers.
> 
> The unwind-sjlj.c problem should occur on most other platforms too, so
> I don't think that problem is ia64-specific.

ah, thanks, will test it, and maybe upgrade to 3.3.3
if this seems necessary ...

best,
Herbert

> 	--david
> 
> Index: gcc/unwind-sjlj.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/unwind-sjlj.c,v
> retrieving revision 1.11.2.2
> diff -u -r1.11.2.2 unwind-sjlj.c
> --- gcc/unwind-sjlj.c	2 May 2003 21:01:21 -0000	1.11.2.2
> +++ gcc/unwind-sjlj.c	14 Feb 2004 00:50:33 -0000
> @@ -22,7 +22,9 @@
>  #include "tconfig.h"
>  #include "tsystem.h"
>  #include "unwind.h"
> +#ifndef inhibit_libc
>  #include "gthr.h"
> +#endif
>  
>  #ifdef __USING_SJLJ_EXCEPTIONS__
>  
> Index: gcc/unwind.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/unwind.h,v
> retrieving revision 1.7.2.6
> diff -u -r1.7.2.6 unwind.h
> --- gcc/unwind.h	4 Sep 2003 09:39:44 -0000	1.7.2.6
> +++ gcc/unwind.h	14 Feb 2004 00:50:33 -0000
> @@ -195,7 +195,9 @@
>     compatible with the standard ABI for IA-64, we inline these.  */
>  
>  #ifdef __ia64__
> -#include <stdlib.h>
> +# ifndef inhibit_libc
> +#  include <stdlib.h>
> +# endif
>  
>  static inline _Unwind_Ptr
>  _Unwind_GetDataRelBase (struct _Unwind_Context *_C)
> Index: gcc/config/ia64/fde-glibc.c
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/ia64/fde-glibc.c,v
> retrieving revision 1.5
> diff -u -r1.5 fde-glibc.c
> --- gcc/config/ia64/fde-glibc.c	15 Dec 2001 11:46:51 -0000	1.5
> +++ gcc/config/ia64/fde-glibc.c	14 Feb 2004 00:50:34 -0000
> @@ -31,6 +31,9 @@
>  #ifndef _GNU_SOURCE
>  #define _GNU_SOURCE
>  #endif
> +
> +#ifndef inhibit_libc
> +
>  #include "config.h"
>  #include <stddef.h>
>  #include <stdlib.h>
> @@ -162,3 +165,5 @@
>  
>    return data.ret;
>  }
> +
> +#endif
> Index: gcc/config/ia64/linux.h
> ===================================================================
> RCS file: /cvs/gcc/gcc/gcc/config/ia64/linux.h,v
> retrieving revision 1.23
> diff -u -r1.23 linux.h
> --- gcc/config/ia64/linux.h	3 Sep 2002 21:09:54 -0000	1.23
> +++ gcc/config/ia64/linux.h	14 Feb 2004 00:50:34 -0000
> @@ -58,7 +58,7 @@
>  /* Do code reading to identify a signal frame, and set the frame
>     state data appropriately.  See unwind-dw2.c for the structs.  */
>  
> -#ifdef IN_LIBGCC2
> +#ifdef x_IN_LIBGCC2
>  #include <signal.h>
>  #include <sys/ucontext.h>
>  

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Sat, Feb 14, 2004 at 02:08:41AM +0100, Herbert Poetzl wrote:
> On Fri, Feb 13, 2004 at 04:58:56PM -0800, David Mosberger wrote:
> > >>>>> On Fri, 13 Feb 2004 22:44:20 +0100, Herbert Poetzl <herbert@13thfloor.at> said:
> > 
> >   >> A recipe for building ia32->ia64 cross-toolchain on Debian can be
> >   >> found here:
> > 
> >   >> http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation
> > 
> >   Herbert> that might work with the ia64 libraries and headers, but it
> >   Herbert> seems to fail, with the headers included in the gcc
> >   Herbert> tarball, for cross compiling, if you get it to compile
> >   Herbert> without (g)libc which should not be required to build the
> >   Herbert> crossgcc and the kernel, I would be very interested ...
> > 
> > Ah, I see now what you mean.  I suspect that's a setup that's rarely
> > tested, so I'm not surprised to see some breakage.
> > 
> > Having said that, I got gcc v3.3.3 20031212 (prerelease) to build with
> > minor tweaks (see patch below).  I'm no GCC-built-environment expert
> > and I'm quite certain that the patch isn't totally correct, but all
> > the unwind-related stuff isn't really needed in your case, because
> > that code only comes into play for exception-handling and C cleanup
> > handlers.
> > 
> > The unwind-sjlj.c problem should occur on most other platforms too, so
> > I don't think that problem is ia64-specific.
> 
> ah, thanks, will test it, and maybe upgrade to 3.3.3
> if this seems necessary ...

okay, status update ... thanks to David, ia64 gcc is now
working, I updated the fix for ia64 and made a testrun for
2.4.25-rc2 ...

linux-2.4.25-rc2        config  dep     kernel  modules

ia64/ia64:		OK	OK	FAILED	FAILED

> best,
> Herbert
> 
> > 	--david
> > 
> > Index: gcc/unwind-sjlj.c
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/gcc/unwind-sjlj.c,v
> > retrieving revision 1.11.2.2
> > diff -u -r1.11.2.2 unwind-sjlj.c
> > --- gcc/unwind-sjlj.c	2 May 2003 21:01:21 -0000	1.11.2.2
> > +++ gcc/unwind-sjlj.c	14 Feb 2004 00:50:33 -0000
> > @@ -22,7 +22,9 @@
> >  #include "tconfig.h"
> >  #include "tsystem.h"
> >  #include "unwind.h"
> > +#ifndef inhibit_libc
> >  #include "gthr.h"
> > +#endif
> >  
> >  #ifdef __USING_SJLJ_EXCEPTIONS__
> >  
> > Index: gcc/unwind.h
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/gcc/unwind.h,v
> > retrieving revision 1.7.2.6
> > diff -u -r1.7.2.6 unwind.h
> > --- gcc/unwind.h	4 Sep 2003 09:39:44 -0000	1.7.2.6
> > +++ gcc/unwind.h	14 Feb 2004 00:50:33 -0000
> > @@ -195,7 +195,9 @@
> >     compatible with the standard ABI for IA-64, we inline these.  */
> >  
> >  #ifdef __ia64__
> > -#include <stdlib.h>
> > +# ifndef inhibit_libc
> > +#  include <stdlib.h>
> > +# endif
> >  
> >  static inline _Unwind_Ptr
> >  _Unwind_GetDataRelBase (struct _Unwind_Context *_C)
> > Index: gcc/config/ia64/fde-glibc.c
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/gcc/config/ia64/fde-glibc.c,v
> > retrieving revision 1.5
> > diff -u -r1.5 fde-glibc.c
> > --- gcc/config/ia64/fde-glibc.c	15 Dec 2001 11:46:51 -0000	1.5
> > +++ gcc/config/ia64/fde-glibc.c	14 Feb 2004 00:50:34 -0000
> > @@ -31,6 +31,9 @@
> >  #ifndef _GNU_SOURCE
> >  #define _GNU_SOURCE
> >  #endif
> > +
> > +#ifndef inhibit_libc
> > +
> >  #include "config.h"
> >  #include <stddef.h>
> >  #include <stdlib.h>
> > @@ -162,3 +165,5 @@
> >  
> >    return data.ret;
> >  }
> > +
> > +#endif
> > Index: gcc/config/ia64/linux.h
> > ===================================================================
> > RCS file: /cvs/gcc/gcc/gcc/config/ia64/linux.h,v
> > retrieving revision 1.23
> > diff -u -r1.23 linux.h
> > --- gcc/config/ia64/linux.h	3 Sep 2002 21:09:54 -0000	1.23
> > +++ gcc/config/ia64/linux.h	14 Feb 2004 00:50:34 -0000
> > @@ -58,7 +58,7 @@
> >  /* Do code reading to identify a signal frame, and set the frame
> >     state data appropriately.  See unwind-dw2.c for the structs.  */
> >  
> > -#ifdef IN_LIBGCC2
> > +#ifdef x_IN_LIBGCC2
> >  #include <signal.h>
> >  #include <sys/ucontext.h>
> >  
> -
> 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/

Re: Kernel Cross Compiling

[David Mosberger]

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

  Herbert> linux-2.4.25-rc2 config dep kernel modules

2.4?  That's pretty hopeless.  2.6 builds out of the box for ia64.

	--david

Re: Kernel Cross Compiling

[Stephen M. Kenton]

The problems with GCC cross builds are known and are
targeted for GCC 3.5 since the changes will apparently be
invasive.  If you have not seen it yet, Dan Kegel has
a very nice package called crosstool with lots of
comments about the contortions of cross compiling.
http://kegel.com/crosstool

smk

Re: Kernel Cross Compiling

[Timothy D. Witham]

 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.

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)

Re: Kernel Cross Compiling

[Herbert Poetzl]

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

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

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Fri, Feb 13, 2004 at 09:26:31PM -0600, Stephen M. Kenton wrote:
> The problems with GCC cross builds are known and are
> targeted for GCC 3.5 since the changes will apparently be
> invasive.  If you have not seen it yet, Dan Kegel has
> a very nice package called crosstool with lots of
> comments about the contortions of cross compiling.
> http://kegel.com/crosstool

thanks for the info, I read/tested that one too, some time
ago, but decided against this approach, as it builds the
glibc, which I do not need for the kernel toolchain at all
and I didn't want to bother with another source that won't
compile on arch xy ... maybe the wrong decision? I don't 
know ...

best,
Herbert

> smk
> -
> 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/

Re: Kernel Cross Compiling

[Timothy D. Witham]

  Well it seems to me it makes more sense to extend rather
than start over.

Tim

On Sat, 2004-02-14 at 05:03, Herbert Poetzl 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 ...
> 
> 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
-- 
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)

re: Kernel Cross Compiling

[Dan Kegel]

Herbert Poetzl <herbert@13thfloor.at> wrote:
> 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 ...

Great idea!

>  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

Wouldn't it be easier to use http://kegel.com/crosstool
which already builds good toolchains for just about every
CPU type?
- Dan

-- 
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/
http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Sat, Feb 14, 2004 at 01:03:22PM -0800, Dan Kegel wrote:
> Herbert Poetzl <herbert@13thfloor.at> wrote:
> >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 ...
> 
> Great idea!
> 
> > 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
> 
> Wouldn't it be easier to use http://kegel.com/crosstool
> which already builds good toolchains for just about every
> CPU type?

yeah Dan, I thought about that, and I guess I'll
give that _another_ try soon, the reason I didn't
choose that path, simply was, that I didn't want
to compile the (g)libc, because I really do not 
need it at all (kernel does not use/require that)
and I didn't want to deal with that one too ...

btw, what archs did you verify? didn't find a 
'success' list or something like that, probably
missed it somehow, anyway, currently I managed
to compile binutils and gcc for:

 alpha, arm, cris, hppa/64, i386, ia64, m68k,
 mips/64, ppc/64, s390, sh/4, sparc/64, v850,
 x86_64 ...

TIA,
Herbert

> - Dan
> 
> -- 
> US citizens: if you're considering voting for Bush, look at these first:
> http://www.misleader.org/
> http://www.cbc.ca/news/background/arar/
> http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Sat, Feb 14, 2004 at 11:25:41AM -0800, Timothy D. Witham wrote:
>   Well it seems to me it makes more sense to extend rather
> than start over.

okay, what do you have in mind, how _can_ we extend
that and _how_ could I _use_ that for linux-vserver?

TIA,
Herbert

> Tim
> 
> On Sat, 2004-02-14 at 05:03, Herbert Poetzl 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 ...
> > 
> > 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
> -- 
> 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)

Re: Kernel Cross Compiling

[Dan Kegel]

Herbert Poetzl wrote:
>>Wouldn't it be easier to use http://kegel.com/crosstool
>>which already builds good toolchains for just about every
>>CPU type?
> 
> 
> yeah Dan, I thought about that, and I guess I'll
> give that _another_ try soon, the reason I didn't
> choose that path, simply was, that I didn't want
> to compile the (g)libc, because I really do not 
> need it at all (kernel does not use/require that)
> and I didn't want to deal with that one too ...

Makes sense.  Simpler is better.

> btw, what archs did you verify? didn't find a 
> 'success' list or something like that, probably
> missed it somehow, anyway, currently I managed
> to compile binutils and gcc for:
> 
>  alpha, arm, cris, hppa/64, i386, ia64, m68k,
>  mips/64, ppc/64, s390, sh/4, sparc/64, v850,
>  x86_64 ...

I think I got most of those built except for hppa, ppc/64,
sparc/64, and v850.  (I've only run the gcc regression
tests on ppc405, ppc750, and sh4 so far, but hope to test more
later.)
Also, IBM seems to be using a variant of my script for ppc64.
- Dan

-- 
US citizens: if you're considering voting for Bush, look at these first:
http://www.misleader.org/
http://www.cbc.ca/news/background/arar/
http://www.house.gov/reform/min/politicsandscience/

Re: Kernel Cross Compiling

[Geert Uytterhoeven]

On Sat, 14 Feb 2004, Herbert Poetzl wrote:
>   linux-2.4.25-rc2        config  dep     kernel  modules
>   m68k/m68k:              OK      OK      OK      OK

Good! :-)

One related question: anyone who knows how to run a cross-depmod, so I can find
missing symbol exports without running depmod on the target?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Sun, Feb 15, 2004 at 12:16:10PM +0100, Geert Uytterhoeven wrote:
> On Sat, 14 Feb 2004, Herbert Poetzl wrote:
> >   linux-2.4.25-rc2        config  dep     kernel  modules
> >   m68k/m68k:              OK      OK      OK      OK
> 
> Good! :-)

yeah but,

			2.6.2-rc3       2.6.3-rc2
[ARCH m68k/m68k]        failed.         failed.       

Bad! :(

> 
> One related question: anyone who knows how to run a cross-depmod, 
> so I can find missing symbol exports without running depmod 
> on the target?

../modutils-2.4.26/configure --target=m68k-linux

seems to do something, so it might even work ...

depmod: ELF file /lib/.../kernel/crypto/aes.o not for this architecture
depmod: ELF file /lib/.../kernel/crypto/blowfish.o not for this architecture

HTH,
Herbert

> Gr{oetje,eeting}s,
> 						Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> 							    -- Linus Torvalds

Re: Kernel Cross Compiling

[Robert Schwebel]

Herbert, 

On Sat, Feb 14, 2004 at 03:21:57PM +0100, Herbert Poetzl wrote:
> > http://kegel.com/crosstool
> 
> thanks for the info, I read/tested that one too, some time
> ago, but decided against this approach, as it builds the
> glibc, which I do not need for the kernel toolchain at all
> and I didn't want to bother with another source that won't
> compile on arch xy ... maybe the wrong decision? I don't 
> know ...

you might also want to have a look at the idea behind PTXdist (see
http://www.pengutronix.de/software/ptxdist_en.html) which is also able
to build toolchains and do all the necessary tweaking, without building
a glibc (just only run 'make xchain-gccstage1' to get a compiler without
glibc). It follows the same approach for the patch repositories like Dan
and we are syncing heavily.

The whole toolchain building is a huge mess at the moment.  

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: Kernel Cross Compiling

[William Lee Irwin III]

On Sat, Feb 14, 2004 at 03:21:57PM +0100, Herbert Poetzl wrote:
>> thanks for the info, I read/tested that one too, some time
>> ago, but decided against this approach, as it builds the
>> glibc, which I do not need for the kernel toolchain at all
>> and I didn't want to bother with another source that won't
>> compile on arch xy ... maybe the wrong decision? I don't 
>> know ...

On Mon, Feb 16, 2004 at 12:28:11AM +0100, Robert Schwebel wrote:
> you might also want to have a look at the idea behind PTXdist (see
> http://www.pengutronix.de/software/ptxdist_en.html) which is also able
> to build toolchains and do all the necessary tweaking, without building
> a glibc (just only run 'make xchain-gccstage1' to get a compiler without
> glibc). It follows the same approach for the patch repositories like Dan
> and we are syncing heavily.
> The whole toolchain building is a huge mess at the moment.  

(a) The idiot thing was screwed wrt. binutils when the things were
	prefixed with e.g. sparc64-linux-gnu-$PROG; I managed to decipher
	where the paths were and just patch in the names of the crossutils.
(b) The stuff produced broken kernels; I had to resort to native builds
	anyway (which far from ideal, since it target violates host/target
	separation), and lost money getting a second of its kind to repair
	that state of affairs.

-- wli

Re: Kernel Cross Compiling

[Peter Chubb]

>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:

>>>>> On Fri, 13 Feb 2004 21:57:43 +0100, Herbert Poetzl <herbert@13thfloor.at> said:
Herbert> I got all headers fixed, except for the ia64, which still
Herbert> doesn't work

David> Something sounds wrong here. You shouldn't have to patch
David> headers.

David> A recipe for building ia32->ia64 cross-toolchain on Debian can
David> be found here:

David>  http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation

He's trying to use gcc 3.3.2 which isn't packaged in toolchain-source
yet.  And he's running on a RedHat-like system.

And there's currently a problem:  To build gcc you need access to an
appropriate libc6 header package; dpkg-cross refuses to install one
without linux-kernel-headers-cross-ia64; but will also not install
linux-kernel-headers.  You need the patch at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=222168

Peter C

Re: Kernel Cross Compiling

[Keith Owens]

On Sun, 15 Feb 2004 18:38:36 +0100, 
Herbert Poetzl <herbert@13thfloor.at> wrote:
>On Sun, Feb 15, 2004 at 12:16:10PM +0100, Geert Uytterhoeven wrote:
>> One related question: anyone who knows how to run a cross-depmod, 
>> so I can find missing symbol exports without running depmod 
>> on the target?
>
>../modutils-2.4.26/configure --target=m68k-linux
>
>seems to do something, so it might even work ...
>
>depmod: ELF file /lib/.../kernel/crypto/aes.o not for this architecture
>depmod: ELF file /lib/.../kernel/crypto/blowfish.o not for this architecture

modutils <= 2.4 was never designed to run in cross compile mode.  The
modules.dep file created at compile time is a courtesy file, in an
attempt to avoid warning messages (no modules.dep) on the very first
boot of a new kernel version.  Once the kernel has been booted, it ahs
its own modules.dep.

Making it run on the target system but handle cross compiled modules
pulls in all the problems associated with build and target having
different word sizes, different endianess and different object
information.  modutils 2.4 is now in stable mode, it is only taking bug
fixes.  A complete rewrite to handle cross compile is not a bug fix.

Bottom line: when building cross compile use make ... DEPMOD=/bin/true
to avoid using the local depmod.

Re: Kernel Cross Compiling

[cliff white]

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

Re: Kernel Cross Compiling

[Herbert Poetzl]

On Mon, Feb 16, 2004 at 01:41:20PM -0800, cliff white wrote:
> On Sat, 14 Feb 2004 14:03:22 +0100
> Herbert Poetzl <herbert@13thfloor.at> wrote:

Hi Cliff!

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

tried that one for vs1.20 (2.4.21,2.4.22,2.4.23) was
a little inflexible, but I didn't understand the results:

PPC-Cross Compile Regress 447 warnings, 21 errors PASS?

and what I would need is the following:

 - vanilla kernel + config which compiles for arch X
 - vanilla kernel + vserver patches + same config
   which is tested for arch X
 - differences in the warnings/errors to the default
   (vanilla) build
 - ability to check a 'special' config 
 
> 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 ) 

currently there are three linux-vserver branches,
stable (2.4), devel (2.4) and experimental (2.6)
very soon the experimental branch will become the
devel branch, and the devel branch the last stable
for (2.4) devel and stable will move on to 2.6 then

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

tried those, but decided not to use them, as they require
building the (g)libc which isN#t required for kernel
builds at all ...

> Several things you/we could do:
> - You could of course use our stuff to run your compilie farm, we're
> 	always glad to help. :)

okay, how could this be done, and what would be my part
especially:
 
 - how to add new patches/releases/branches
 - how to activate a testbuild for a kernel/patch 
   combination
 - how to use it 'just' for a test, to detect and
   correct build errors (the main purpose)

> - we always need help with the project. Mailing list is 
>       plm-devel@lists.sourceforge.net.

how could I help?

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

currently my cross compile toolchains support the
following archs:

  alpha arm cris hppa hppa64 i386 ia64 m68k mips mips64 
  ppc ppc64 s390 sh sh64 sparc sparc64 v850 x86_64

the 'defconfig' only works for a subset of those and
some arch have even troubles building without heavy
patches ...

so planning sounds good, but we are already supporting
  alpha, hppa64, i386, s390, sparc/64 and x86_64

> ( we noticed you are doing a defconfig. We've done separate config 
> files for those builds, to reduce time ) 

sounds like a reasonable approach ...

> hope to hear from you
> cliffw

TIA,
Herbert

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

Re: Kernel Cross Compiling

[Jim Wilson]

On Fri, 2004-02-13 at 16:58, David Mosberger wrote:
>   >> A recipe for building ia32->ia64 cross-toolchain on Debian can be
>   >> found here:
>   >> http://www.gelato.unsw.edu.au/IA64wiki/CrossCompilation

I recommend Dan Kegel's page for anyone trying to build a cross compiler
to linux.  See
	http://kegel.com/crosstool
This isn't very hard to follow, and it gives you a properly configured
and built gcc/glibc for the target.

I don't recommend the inhibit_libc trick for building linux crosses.  It
may work well enough for kernel builds, but it will give you a subtly
broken gcc, and that may lead to confusion later.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Kernel Cross Compiling

[Maciej W. Rozycki]

On Fri, 13 Feb 2004, Herbert Poetzl wrote:

>    mips/mips64:
> 	seem to use the 'obsoleted' -mcpu= option
> 	which results in a cc1: error: invalid option 
> 	`cpu=<cpu-here>'

 FYI, this has been addressed in the MIPS CVS tree not so long ago, so
changes are not merged to the mainline yet.  Actually, even the CVS
version isn't fully complete yet -- a small update is still pending
approval.  The problem isn't related to doing a build with cross-tools --
it happens when building natively as well.

 Otherwise, cross-compilation is the usual way of doing builds for MIPS
and it works in general.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Kernel Cross Compiling

[Judith Lebzelter]

>
> tried that one for vs1.20 (2.4.21,2.4.22,2.4.23) was
> a little inflexible, but I didn't understand the results:
>
> PPC-Cross Compile Regress 447 warnings, 21 errors PASS?

The Compile Regress is John Cherry's filter which we run through plm,
and I include with the plm package.  The 'PASS' status is based only
on the main compiles, due to the fact that some for the compiles of the
'defconfig', 'allnoconfig', 'allyesconfig' and 'allmodconfig'.  It also
goes though the directories and compiles the objects individually, but
this does contribute to fail the test.

There is a -s option to only run 'defconfig' and 'allmodconfig' in the
newer versions of this script.


>
> and what I would need is the following:
>
>  - vanilla kernel + config which compiles for arch X
>  - vanilla kernel + vserver patches + same config
>    which is tested for arch X
>  - differences in the warnings/errors to the default
>    (vanilla) build
>  - ability to check a 'special' config
>

PLM is as application for tracking base releases and patches to the
release, on which you can configure 'filters' to run and store the
results.  Each architecture or type of config you want to check could be
set up as an individual filter.  The kconfig files I use are generally
part of the specific filter which I've set up.

The source trees (base + patches) are then also easily available to other
plm clients.  In our case STP.


> > 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 )
>
> currently there are three linux-vserver branches,
> stable (2.4), devel (2.4) and experimental (2.6)
> very soon the experimental branch will become the
> devel branch, and the devel branch the last stable
> for (2.4) devel and stable will move on to 2.6 then
>
> > We do some cross compiles, using Dan Kegel's fine tools.
>
> tried those, but decided not to use them, as they require
> building the (g)libc which isN#t required for kernel
> builds at all ...
>
> > Several things you/we could do:
> > - You could of course use our stuff to run your compilie farm, we're
> > 	always glad to help. :)
>
> okay, how could this be done, and what would be my part
> especially:
>
>  - how to add new patches/releases/branches
>  - how to activate a testbuild for a kernel/patch
>    combination
>  - how to use it 'just' for a test, to detect and
>    correct build errors (the main purpose)
>

To use our PLM:
   *  We would need to build the cross-compilers here on our compile farm.
      The cross-compilers would need to be built in an easily reproduced
      manner--to be installed on multiple machines and easily re-built
   *  Design/edit filters to suit your purpose with a reasonably short
      run time.  We would set them up in PLM.
   *  Patch submission is through the PLM web interface:
            https://www.osdl.org/plm-cgi/plm?module=addpatch
      You just upload a text diff file.
   *  The results are summarised in the output of the filter which you set
      up and available online.
To Set up your own PLM:
   *  You could use our PLM software to set up your own automated
      source/filter tracking system.
          Home:  http://developer.osdl.org/dev/plm/
          Download:  http://sourceforge.net/projects/plm
   *  There is a script to build an rpm in the source.   There are some
      admin tools to set-up filters, which you grab from a web server.
   *  It runs on a MySQL database.
   *  You design/edit filters to suit exactly your purpose.

> > - we always need help with the project. Mailing list is
> >       plm-devel@lists.sourceforge.net.
>
> how could I help?

We are planning quite a few updates to PLM soon, including creating base
patches from CVS and bk pulls, Storing build information with the patch
sets,  Improving the installation scripts, etc.

If the tool doesn't do all you would like any input would be great too.
It sounds like maybe a page to display all the recent results of a
particular filter (ie sparc64_default_compile) would be nice.

>
> > - 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.
>
> currently my cross compile toolchains support the
> following archs:
>
>   alpha arm cris hppa hppa64 i386 ia64 m68k mips mips64
>   ppc ppc64 s390 sh sh64 sparc sparc64 v850 x86_64
>

A very impressive list. :) Do you have automated scripts for setting up
your toolchains on other systems? Like ours?

> the 'defconfig' only works for a subset of those and
> some arch have even troubles building without heavy
> patches ...
>
> so planning sounds good, but we are already supporting
>   alpha, hppa64, i386, s390, sparc/64 and x86_64

Nobody had shown much interest in the others, so we set our
priorities...

Thanks;
Judith Lebzelter
OSDL

>
> > ( we noticed you are doing a defconfig. We've done separate config
> > files for those builds, to reduce time )
>
> sounds like a reasonable approach ...
>
> > hope to hear from you
> > cliffw
>
> TIA,
> Herbert
>
> > > 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
>
>
>
>

Re: Kernel Cross Compiling

[Herbert Poetzl]

Hi Judith!

On Tue, Feb 17, 2004 at 01:51:19PM -0800, Judith Lebzelter wrote:
> > tried that one for vs1.20 (2.4.21,2.4.22,2.4.23) was
> > a little inflexible, but I didn't understand the results:
> >
> > PPC-Cross Compile Regress 447 warnings, 21 errors PASS?
> 
> The Compile Regress is John Cherry's filter which we run through plm,
> and I include with the plm package.  The 'PASS' status is based only
> on the main compiles, due to the fact that some for the compiles of the
> 'defconfig', 'allnoconfig', 'allyesconfig' and 'allmodconfig'.  It also
> goes though the directories and compiles the objects individually, but
> this does contribute to fail the test.
> 
> There is a -s option to only run 'defconfig' and 'allmodconfig' in the
> newer versions of this script.
> 
> > and what I would need is the following:
> >
> >  - vanilla kernel + config which compiles for arch X
> >  - vanilla kernel + vserver patches + same config
> >    which is tested for arch X
> >  - differences in the warnings/errors to the default
> >    (vanilla) build
> >  - ability to check a 'special' config
> 
> PLM is as application for tracking base releases and patches to the
> release, on which you can configure 'filters' to run and store the
> results.  Each architecture or type of config you want to check could be
> set up as an individual filter.  The kconfig files I use are generally
> part of the specific filter which I've set up.

okay, sounds basically useful ...

> The source trees (base + patches) are then also easily available to other
> plm clients.  In our case STP.
> 
> > > 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 )
> >
> > currently there are three linux-vserver branches,
> > stable (2.4), devel (2.4) and experimental (2.6)
> > very soon the experimental branch will become the
> > devel branch, and the devel branch the last stable
> > for (2.4) devel and stable will move on to 2.6 then
> >
> > > We do some cross compiles, using Dan Kegel's fine tools.
> >
> > tried those, but decided not to use them, as they require
> > building the (g)libc which isN#t required for kernel
> > builds at all ...
> >
> > > Several things you/we could do:
> > > - You could of course use our stuff to run your compilie farm, we're
> > > 	always glad to help. :)
> >
> > okay, how could this be done, and what would be my part
> > especially:
> >
> >  - how to add new patches/releases/branches
> >  - how to activate a testbuild for a kernel/patch
> >    combination
> >  - how to use it 'just' for a test, to detect and
> >    correct build errors (the main purpose)
> >
> 
> To use our PLM:
>    *  We would need to build the cross-compilers here on our compile farm.
>       The cross-compilers would need to be built in an easily reproduced
>       manner--to be installed on multiple machines and easily re-built

thought so, that was also my concern in the first place
(see details below)

>    *  Design/edit filters to suit your purpose with a reasonably short
>       run time.  We would set them up in PLM.
>    *  Patch submission is through the PLM web interface:
>             https://www.osdl.org/plm-cgi/plm?module=addpatch
>       You just upload a text diff file.
>    *  The results are summarised in the output of the filter which you set
>       up and available online.

basically the only missing feature would be building the
differences between a 'vanilla' build run and a vserver
kernel build run, which I think could be done via the
web interface or, if this is interesting for you too,
as addition to the PLM ...

> To Set up your own PLM:
>    *  You could use our PLM software to set up your own automated
>       source/filter tracking system.
>           Home:  http://developer.osdl.org/dev/plm/
>           Download:  http://sourceforge.net/projects/plm
>    *  There is a script to build an rpm in the source.   There are some
>       admin tools to set-up filters, which you grab from a web server.
>    *  It runs on a MySQL database.
>    *  You design/edit filters to suit exactly your purpose.

that would wbe an option, maybe for testing purposes
but as many people pointed out, not as useful ...

> > > - we always need help with the project. Mailing list is
> > >       plm-devel@lists.sourceforge.net.
> >
> > how could I help?
> 
> We are planning quite a few updates to PLM soon, including creating base
> patches from CVS and bk pulls, Storing build information with the patch
> sets,  Improving the installation scripts, etc.
> 
> If the tool doesn't do all you would like any input would be great too.
> It sounds like maybe a page to display all the recent results of a
> particular filter (ie sparc64_default_compile) would be nice.
> 
> >
> > > - 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.
> >
> > currently my cross compile toolchains support the
> > following archs:
> >
> >   alpha arm cris hppa hppa64 i386 ia64 m68k mips mips64
> >   ppc ppc64 s390 sh sh64 sparc sparc64 v850 x86_64
> 
> A very impressive list. :) Do you have automated scripts for setting up
> your toolchains on other systems? Like ours?

sure, made them available some time ago, you can get
the spec files and patches for binutils and gcc at 

 http://vserver.13thfloor.at/Stuff/Cross/

I'm currently building Dan's toolschains (or better
working on it, as they refuse to compile with my gcc,
which I have to admit, is a little outdated) to
compare my toolchains (gcc) with them, because it was
mentioned that building gcc the way I do it, would
introduce subtle compiler bugs, which I want to verify 

of course they can be built without RPMs too, but that
was the simplest way for me atm ...

> > the 'defconfig' only works for a subset of those and
> > some arch have even troubles building without heavy
> > patches ...
> >
> > so planning sounds good, but we are already supporting
> >   alpha, hppa64, i386, s390, sparc/64 and x86_64
> 
> Nobody had shown much interest in the others, so we set our
> priorities...

okay *showing interest* in at least the vserver 
supported platforms alpha, hppa64, s390, sparc/64
and x86_64 (ia32/64 and ppc/64 are already supported)

TIA,
Herbert

> Thanks;
> Judith Lebzelter
> OSDL
> 
> >
> > > ( we noticed you are doing a defconfig. We've done separate config
> > > files for those builds, to reduce time )
> >
> > sounds like a reasonable approach ...
> >
> > > hope to hear from you
> > > cliffw
> >
> > TIA,
> > Herbert
> >
> > > > 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
> >
> >
> >
> >
> 
> 
> 
> 
>