Re: multiboot

[Johan Rydberg <jrydberg@night.trouble.net>]

Marco Gerards <metgerards@student.han.nl> writes:

> Johan Rydberg <jrydberg@night.trouble.net> writes:
>
>> The initial problem was that AC_CHECK_SIZEOF doesn't work if you're
>> cross-compiling.  I fixed this by using AC_COMPILE_CHECK_SIZEOF [1]
>> instead.
>
> This sounds right to me, but I do not see this in the patch...

Of course not.  I didn't include it :) I'm sure you can download the
m4 macro, install it in acinclude.m4 and change AC_CHECK_SIZEOF to
AC_COMPILE_CHECK_SIZEOF.  If you're as lazy as I am, I can include it
in a later patch.

>> But the major problem is that parts of GRUB2 requires a C library to
>> be installed, at least headers such as alloca.h and stdint.h.  Is this
>> really a valid demand?  
>
> Is this required for grubof?  IIRC those headers are not a part of the
> C library, but a part of gcc or libgcc or so.  Am I right about that?

My GCC installation (3.2.2 configured for powerpc-elf) installed the
following headers:

/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/syslimits.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/stdarg.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/stddef.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/varargs.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/stdbool.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/iso646.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/ppc-asm.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/altivec.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/limits.h
/gnu/lib/gcc-lib/powerpc-elf/3.2.2/include/float.h

And my native installation of GCC (3.3.4 configured for i486-linux)
includes:

/usr/lib/gcc-lib/i486-linux/3.3.4/include/iso646.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/float.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/limits.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/stdarg.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/stdbool.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/stddef.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/syslimits.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/unwind.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/varargs.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/mmintrin.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/emmintrin.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/pmmintrin.h
/usr/lib/gcc-lib/i486-linux/3.3.4/include/xmmintrin.h

A little more research shows that both stdint.h and alloca.h is part
of glibc:

$ head -2 /usr/include/stdint.h 
/* Copyright (C) 1997, 1998, 1999, 2000, 2001 Free Software Foundation, Inc.
   This file is part of the GNU C Library.
$ head -2 /usr/include/alloca.h 
/* Copyright (C) 1992, 1996, 1997, 1998, 1999 Free Software Foundation, Inc.
   This file is part of the GNU C Library.

So either we stop using then, or write our own versions.

> Instead of alloca we can also use something like:
> [...]
> In most cases that will remove the dependency on alloca.  IMHO it is
> better not to use alloca.

It is also possible to use __builtin_alloca if alloca.h is missing,
provided that there's a requirement for GCC.  

>> That brings us the next issue; BUILD_CC is used to build _everything_,
>> including the host-specific object files, and since BUILD_CC is set to
>> /usr/bin/gcc in my cross-compiler environment it will try to compile
>> PPC assembler sources with a i386 compiler.  Not good.
>>
>> My suggestion is to create a new class for programs that should be
>> host-specific, and let Utilities be compiled on the build machine.
>> See the patch.  
>
> Ok, that sounds sane.  But what if you really want to cross-compile a
> complete system (including libc, GRUB, etc)?

Good call.  I'm not sure what to do.  Got any ideas? 

> Can you make one big patch with a changelog entry so it can be
> committed after Okuji agrees with the patch?

I would prefer Okuji looked at the changes to genmk.rb before that.

~j