Report: compil error on OSX for target=i386

Report: compil error on OSX for target=i386

[Yves Blusseau]

Hi,

can't compil grub2 on OSX with target=i386:

./configure --prefix=/opt --target=i386

*******************************************************
GRUB2 will be compiled with following components:
Platform: i386-pc
grub-emu: Yes
USB support for grub-emu: No (need libusb library)
With memory debugging: No
grub-pe2elf will not be built
efiemu runtime: No (cannot compile with -m64 -mcmodel=large -mno-red- 
zone -nostdlib)
grub-fstest: Yes
grub-mkfont: Yes
*******************************************************

make

loader/i386/linux.c: In function ‘grub_linux_boot’:
loader/i386/linux.c:563: error: can't find a register in class ‘BREG’  
while reloading ‘asm’
make: *** [linux_mod-loader_i386_linux.o] Error 1

Yves Blusseau

Re: Report: compil error on OSX for target=i386

[Bean]

Hi,

I also encounter this problem with apple gcc 4.0, the fix is to replace:

asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
(params->code32_start));

With:
  asm volatile ("movl %0, %%ecx" : : "m" (params->code32_start));
  asm volatile ("movl %0, %%esi" : : "m" (real_mode_mem));

  asm volatile ("xorl %%ebx, %%ebx" : : );
  asm volatile ("jmp *%%ecx" : : );

On Sat, Aug 8, 2009 at 10:34 PM, Yves Blusseau<blusseau@zetam.org> wrote:
> Hi,
>
> can't compil grub2 on OSX with target=i386:
>
> ./configure --prefix=/opt --target=i386
>
> *******************************************************
> GRUB2 will be compiled with following components:
> Platform: i386-pc
> grub-emu: Yes
> USB support for grub-emu: No (need libusb library)
> With memory debugging: No
> grub-pe2elf will not be built
> efiemu runtime: No (cannot compile with -m64 -mcmodel=large -mno-red-zone
> -nostdlib)
> grub-fstest: Yes
> grub-mkfont: Yes
> *******************************************************
>
> make
>
> loader/i386/linux.c: In function ‘grub_linux_boot’:
> loader/i386/linux.c:563: error: can't find a register in class ‘BREG’ while
> reloading ‘asm’
> make: *** [linux_mod-loader_i386_linux.o] Error 1
>
> Yves Blusseau
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Bean

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

On Sat, Aug 8, 2009 at 4:44 PM, Bean<bean123ch@gmail.com> wrote:
> Hi,
>
> I also encounter this problem with apple gcc 4.0, the fix is to replace:
>
> asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
> (params->code32_start));
>
> With:
>  asm volatile ("movl %0, %%ecx" : : "m" (params->code32_start));
>  asm volatile ("movl %0, %%esi" : : "m" (real_mode_mem));
>
>  asm volatile ("xorl %%ebx, %%ebx" : : );
>  asm volatile ("jmp *%%ecx" : : );
This code has absolutely no guaranty to work since C can change
registers between asm parts. In long term I was planning to replace
this code with use of relocator framework
>
> On Sat, Aug 8, 2009 at 10:34 PM, Yves Blusseau<blusseau@zetam.org> wrote:
>> Hi,
>>
>> can't compil grub2 on OSX with target=i386:
>>
>> ./configure --prefix=/opt --target=i386
>>
>> *******************************************************
>> GRUB2 will be compiled with following components:
>> Platform: i386-pc
>> grub-emu: Yes
>> USB support for grub-emu: No (need libusb library)
>> With memory debugging: No
>> grub-pe2elf will not be built
>> efiemu runtime: No (cannot compile with -m64 -mcmodel=large -mno-red-zone
>> -nostdlib)
>> grub-fstest: Yes
>> grub-mkfont: Yes
>> *******************************************************
>>
>> make
>>
>> loader/i386/linux.c: In function ‘grub_linux_boot’:
>> loader/i386/linux.c:563: error: can't find a register in class ‘BREG’ while
>> reloading ‘asm’
>> make: *** [linux_mod-loader_i386_linux.o] Error 1
>>
>> Yves Blusseau
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/grub-devel
>>
>
>
>
> --
> Bean
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Bean]

On Sat, Aug 8, 2009 at 10:47 PM, Vladimir 'phcoder'
Serbinenko<phcoder@gmail.com> wrote:
> On Sat, Aug 8, 2009 at 4:44 PM, Bean<bean123ch@gmail.com> wrote:
>> Hi,
>>
>> I also encounter this problem with apple gcc 4.0, the fix is to replace:
>>
>> asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
>> (params->code32_start));
>>
>> With:
>>  asm volatile ("movl %0, %%ecx" : : "m" (params->code32_start));
>>  asm volatile ("movl %0, %%esi" : : "m" (real_mode_mem));
>>
>>  asm volatile ("xorl %%ebx, %%ebx" : : );
>>  asm volatile ("jmp *%%ecx" : : );
> This code has absolutely no guaranty to work since C can change
> registers between asm parts. In long term I was planning to replace
> this code with use of relocator framework

Hi,

I've examined the generated code with otool and it doesn't insert
extra instruction. Anyway, it would be nice if you can make it more
fail proof.

-- 
Bean

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Sat, Aug 08, 2009 at 10:44:25PM +0800, Bean wrote:
> Hi,
> 
> I also encounter this problem with apple gcc 4.0, the fix is to replace:
> 
> asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
> (params->code32_start));
> 
> With:
>   asm volatile ("movl %0, %%ecx" : : "m" (params->code32_start));
>   asm volatile ("movl %0, %%esi" : : "m" (real_mode_mem));
> 
>   asm volatile ("xorl %%ebx, %%ebx" : : );
>   asm volatile ("jmp *%%ecx" : : );

I think I did precisely the opposite change a while ago, with the purpose of
general cleanup (to make it more compact and avoid generating unnecessary
instructions).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

On Mon, Aug 10, 2009 at 1:41 PM, Robert Millan<rmh@aybabtu.com> wrote:
> On Sat, Aug 08, 2009 at 10:44:25PM +0800, Bean wrote:
>> Hi,
>>
>> I also encounter this problem with apple gcc 4.0, the fix is to replace:
>>
>> asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
>> (params->code32_start));
>>
>> With:
>>   asm volatile ("movl %0, %%ecx" : : "m" (params->code32_start));
>>   asm volatile ("movl %0, %%esi" : : "m" (real_mode_mem));
>>
>>   asm volatile ("xorl %%ebx, %%ebx" : : );
>>   asm volatile ("jmp *%%ecx" : : );
>
> I think I did precisely the opposite change a while ago, with the purpose of
> general cleanup (to make it more compact and avoid generating unnecessary
> instructions).
What about following compromise:
diff --git a/loader/i386/linux.c b/loader/i386/linux.c
index 4144384..1380eb8 100644
--- a/loader/i386/linux.c
+++ b/loader/i386/linux.c
@@ -543,7 +543,8 @@ grub_linux_boot (void)
   asm volatile ("lgdt %0" : : "m" (gdt_desc));

   /* Enter Linux.  */
-  asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
(params->code32_start));
+  asm volatile ("xorl %%ebx, %%ebx\n"
+                     "jmp *%1" : : "S" (real_mode_mem), "g"
(params->code32_start));

 #endif



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Sat, Aug 22, 2009 at 08:00:10PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> On Mon, Aug 10, 2009 at 1:41 PM, Robert Millan<rmh@aybabtu.com> wrote:
> > On Sat, Aug 08, 2009 at 10:44:25PM +0800, Bean wrote:
> >> Hi,
> >>
> >> I also encounter this problem with apple gcc 4.0, the fix is to replace:
> >>
> >> asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
> >> (params->code32_start));
> >>
> >> With:
> >>   asm volatile ("movl %0, %%ecx" : : "m" (params->code32_start));
> >>   asm volatile ("movl %0, %%esi" : : "m" (real_mode_mem));
> >>
> >>   asm volatile ("xorl %%ebx, %%ebx" : : );
> >>   asm volatile ("jmp *%%ecx" : : );
> >
> > I think I did precisely the opposite change a while ago, with the purpose of
> > general cleanup (to make it more compact and avoid generating unnecessary
> > instructions).
> What about following compromise:
> [...]

I'm not sure what's the problem here.  AFAIK inline assembly had this syntax
with GCC 4.0 already.  Did Apple cripple it in their version of GCC ?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

>> What about following compromise:
>> [...]
>
> I'm not sure what's the problem here.  AFAIK inline assembly had this syntax
> with GCC 4.0 already.  Did Apple cripple it in their version of GCC ?
Yes. They don't allow usage of %ebx/%rbx in constraints and clobbered registers
>
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

> What about following compromise:
> diff --git a/loader/i386/linux.c b/loader/i386/linux.c
> index 4144384..1380eb8 100644
> --- a/loader/i386/linux.c
> +++ b/loader/i386/linux.c
> @@ -543,7 +543,8 @@ grub_linux_boot (void)
>   asm volatile ("lgdt %0" : : "m" (gdt_desc));
>
>   /* Enter Linux.  */
> -  asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
> (params->code32_start));
> +  asm volatile ("xorl %%ebx, %%ebx\n"
> +                     "jmp *%1" : : "S" (real_mode_mem), "g"
> (params->code32_start));
>
>  #endif
>
Is this compromise acceptable?
-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

>> What about following compromise:
>> diff --git a/loader/i386/linux.c b/loader/i386/linux.c
>> index 4144384..1380eb8 100644
>> --- a/loader/i386/linux.c
>> +++ b/loader/i386/linux.c
>> @@ -543,7 +543,8 @@ grub_linux_boot (void)
>>   asm volatile ("lgdt %0" : : "m" (gdt_desc));
>>
>>   /* Enter Linux.  */
>> -  asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
>> (params->code32_start));
>> +  asm volatile ("xorl %%ebx, %%ebx\n"
>> +                     "jmp *%1" : : "S" (real_mode_mem), "g"
>> (params->code32_start));
>>
>>  #endif
>>
> Is this compromise acceptable?

Compil and work on OSX.

Is it ok to commit it ?

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Mon, Aug 31, 2009 at 11:10:17PM +0200, Yves Blusseau wrote:
>>> What about following compromise:
>>> diff --git a/loader/i386/linux.c b/loader/i386/linux.c
>>> index 4144384..1380eb8 100644
>>> --- a/loader/i386/linux.c
>>> +++ b/loader/i386/linux.c
>>> @@ -543,7 +543,8 @@ grub_linux_boot (void)
>>>   asm volatile ("lgdt %0" : : "m" (gdt_desc));
>>>
>>>   /* Enter Linux.  */
>>> -  asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
>>> (params->code32_start));
>>> +  asm volatile ("xorl %%ebx, %%ebx\n"
>>> +                     "jmp *%1" : : "S" (real_mode_mem), "g"
>>> (params->code32_start));
>>>
>>>  #endif
>>>
>> Is this compromise acceptable?
>
> Compil and work on OSX.
>
> Is it ok to commit it ?

Apple is free to cripple the version of GCC they're shipping (we wanted
them to have this freedom, even if they're unfriendly towards free software).
I think it's short-sighted, but it's their problem.

However, on our side, I'm not satisfied at all with accomodating to arbitrary
limitations like this one.  This seems like a slippery slope.  If we do it
now, what's the next one?

It's much easier to make official GCC a build requirement.  People hacking
on GRUB source, or distributors (e.g. Fink) should have no problem with a
dependency on GCC.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]


Le 1 sept. 09 à 13:46, Robert Millan a écrit :

> On Mon, Aug 31, 2009 at 11:10:17PM +0200, Yves Blusseau wrote:
>>>> What about following compromise:
>>>> diff --git a/loader/i386/linux.c b/loader/i386/linux.c
>>>> index 4144384..1380eb8 100644
>>>> --- a/loader/i386/linux.c
>>>> +++ b/loader/i386/linux.c
>>>> @@ -543,7 +543,8 @@ grub_linux_boot (void)
>>>>  asm volatile ("lgdt %0" : : "m" (gdt_desc));
>>>>
>>>>  /* Enter Linux.  */
>>>> -  asm volatile ("jmp *%2" : : "b" (0), "S" (real_mode_mem), "g"
>>>> (params->code32_start));
>>>> +  asm volatile ("xorl %%ebx, %%ebx\n"
>>>> +                     "jmp *%1" : : "S" (real_mode_mem), "g"
>>>> (params->code32_start));
>>>>
>>>> #endif
>>>>
>>> Is this compromise acceptable?
>>
>> Compil and work on OSX.
>>
>> Is it ok to commit it ?
>
> Apple is free to cripple the version of GCC they're shipping (we  
> wanted
> them to have this freedom, even if they're unfriendly towards free  
> software).
> I think it's short-sighted, but it's their problem.
>
> However, on our side, I'm not satisfied at all with accomodating to  
> arbitrary
> limitations like this one.  This seems like a slippery slope.  If we  
> do it
> now, what's the next one?
>
> It's much easier to make official GCC a build requirement.  People  
> hacking
> on GRUB source, or distributors (e.g. Fink) should have no problem  
> with a
> dependency on GCC.

So what you can do because currently we can't compil grub on OSX:

gcc-4.2 -Iloader/i386 -I./loader/i386 -I. -I./include -I./include - 
Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing- 
prototypes                  -Wundef -Wstrict-prototypes -g -Os -falign- 
jumps=1 -falign-loops=1 -falign-functions=1 -DAPPLE_CC=1 -fnested- 
functions -m32 -fno-stack-protector -mno-stack-arg-probe -fno-builtin - 
mrtd -mregparm=3 -m32 -MD -c -o linux_mod-loader_i386_linux.o loader/ 
i386/linux.c
loader/i386/linux.c: In function ‘grub_linux_boot’:
loader/i386/linux.c:546: error: can't find a register in class ‘BREG’  
while reloading ‘asm’
loader/i386/linux.c:542: error: ‘asm’ operand has impossible constraints
loader/i386/linux.c:543: error: ‘asm’ operand has impossible constraints
loader/i386/linux.c:546: error: ‘asm’ operand has impossible constraints
make: *** [linux_mod-loader_i386_linux.o] Error 1


Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

>>
>> Compil and work on OSX.
>>
>> Is it ok to commit it ?
>
> However, on our side, I'm not satisfied at all with accomodating to arbitrary
> limitations like this one.  This seems like a slippery slope.  If we do it
> now, what's the next one?
I agree that we shouldn't support a compiler if it requires a major
inconvenience for GNU, GNU/* developers. However I also think it has
to be decided on case-by-case basis. In this particular case I believe
that using
  /* Enter Linux.  */
  asm volatile ("xorl %%ebx, %%ebx\n"
                "jmp *%1" : : "S" (real_mode_mem), "a" (params->code32_start));
is of any trouble.
>
> It's much easier to make official GCC a build requirement.  People hacking
> on GRUB source, or distributors (e.g. Fink) should have no problem with a
> dependency on GCC.
>
It won't do a lot of difference for people really wanting to compile
GRUB. However it makes entry barrier higher. I know that primary goal
of GNU is to provide freedom to freedom-aware people and that users of
proprietary OSes usually don't care about freedom but I also believe
that spreading the word is important. I personally felt the power of
software freedom only when I started coding and recompiling. If users
try the freedom with GRUB they may in the future value it and convert
at later time
> --
> Robert Millan
>
>  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
>  how) you may access your data; but nobody's threatening your freedom: we
>  still allow you to remove your data and not access it at all."
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Thu, Sep 03, 2009 at 11:01:23PM +0200, Yves Blusseau wrote:
>>
>> It's much easier to make official GCC a build requirement.  People  
>> hacking
>> on GRUB source, or distributors (e.g. Fink) should have no problem  
>> with a
>> dependency on GCC.
>
> So what you can do because currently we can't compil grub on OSX:
>
> gcc-4.2 -Iloader/i386 -I./loader/i386 -I. -I./include -I./include -Wall 
> -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes                
>   -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1 -falign-loops=1 
> -falign-functions=1 -DAPPLE_CC=1 -fnested-functions -m32 
> -fno-stack-protector -mno-stack-arg-probe -fno-builtin -mrtd -mregparm=3 
> -m32 -MD -c -o linux_mod-loader_i386_linux.o loader/i386/linux.c
> loader/i386/linux.c: In function ‘grub_linux_boot’:
> loader/i386/linux.c:546: error: can't find a register in class ‘BREG’  
> while reloading ‘asm’
> loader/i386/linux.c:542: error: ‘asm’ operand has impossible constraints
> loader/i386/linux.c:543: error: ‘asm’ operand has impossible constraints
> loader/i386/linux.c:546: error: ‘asm’ operand has impossible constraints
> make: *** [linux_mod-loader_i386_linux.o] Error 1

I assume you installed Apple's version of GCC.  Can you try with an official
GCC release?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Thu, Sep 03, 2009 at 11:33:51PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> > It's much easier to make official GCC a build requirement.  People hacking
> > on GRUB source, or distributors (e.g. Fink) should have no problem with a
> > dependency on GCC.
> >
> It won't do a lot of difference for people really wanting to compile
> GRUB. However it makes entry barrier higher.

I can't participate in a debate about an entry barrier which hasn't been
explained.  Installing GCC is a requirement, among others (autoconf, ruby,
bison...) which are no problem at all on other platforms.

Is there any reason why having build requirements is a problem on MacOS?  If
there is, how come this is not a problem for e.g. autoconf?

Does installing GCC on MacOS require significant expertise that someone who
wants to compile GRUB from source wouldn't be able to deal with?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 2226 bytes --]


Le 4 sept. 09 à 13:48, Robert Millan a écrit :

> On Thu, Sep 03, 2009 at 11:01:23PM +0200, Yves Blusseau wrote:
>>>
>>> It's much easier to make official GCC a build requirement.  People
>>> hacking
>>> on GRUB source, or distributors (e.g. Fink) should have no problem
>>> with a
>>> dependency on GCC.
>>
>> So what you can do because currently we can't compil grub on OSX:
>>
>> gcc-4.2 -Iloader/i386 -I./loader/i386 -I. -I./include -I./include - 
>> Wall
>> -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes
>>  -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1 -falign-loops=1
>> -falign-functions=1 -DAPPLE_CC=1 -fnested-functions -m32
>> -fno-stack-protector -mno-stack-arg-probe -fno-builtin -mrtd - 
>> mregparm=3
>> -m32 -MD -c -o linux_mod-loader_i386_linux.o loader/i386/linux.c
>> loader/i386/linux.c: In function ‘grub_linux_boot’:
>> loader/i386/linux.c:546: error: can't find a register in class ‘BREG’
>> while reloading ‘asm’
>> loader/i386/linux.c:542: error: ‘asm’ operand has impossible  
>> constraints
>> loader/i386/linux.c:543: error: ‘asm’ operand has impossible  
>> constraints
>> loader/i386/linux.c:546: error: ‘asm’ operand has impossible  
>> constraints
>> make: *** [linux_mod-loader_i386_linux.o] Error 1
>
> I assume you installed Apple's version of GCC.  Can you try with an  
> official
> GCC release?

Yes, i have compiled on a true mac (Leopard 10.5.7) with the gcc-4.2.1  
version.

I have tried to compil with a mac port of gcc 4.4 but configure report  
an error (about the linker):

checking whether target compiler is working... no
configure: error: cannot compile for the target

and if i look into the config.log it's because it use the default  
apple linker tool witch don't recognize some arguments:

configure:5882: gcc-mp-4.4 -o conftest -Wall -W -Wshadow -Wpointer- 
arith -Wmissing-prototypes  -Wundef -Wstrict-prototypes -g -Os -falign- 
jumps=1 -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm -m32 - 
fno-stack-protector -mno-stack-arg-probe -nostdlib -Wl,-- 
defsym,___main=0x8100   -m32 conftest.c  >&5
ld: unknown option: --defsym
collect2: ld returned 1 exit status

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Michal Suchanek]

2009/9/4 Robert Millan <rmh@aybabtu.com>:
> On Thu, Sep 03, 2009 at 11:33:51PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>> > It's much easier to make official GCC a build requirement.  People hacking
>> > on GRUB source, or distributors (e.g. Fink) should have no problem with a
>> > dependency on GCC.
>> >
>> It won't do a lot of difference for people really wanting to compile
>> GRUB. However it makes entry barrier higher.
>
> I can't participate in a debate about an entry barrier which hasn't been
> explained.  Installing GCC is a requirement, among others (autoconf, ruby,
> bison...) which are no problem at all on other platforms.
>
> Is there any reason why having build requirements is a problem on MacOS?  If
> there is, how come this is not a problem for e.g. autoconf?
>
> Does installing GCC on MacOS require significant expertise that someone who
> wants to compile GRUB from source wouldn't be able to deal with?

Hello,

I think that the expertise required to build gcc on a somewhat exotic
platform (OS X) is more than what is required to build a small package
(grub).

Typically the compilation of another C compiler is considered somewhat
advanced while building a package is the common way of installing
opensource software.

I have built gcc a few times as a last resort when the compiler
variant I wanted was not available prepackaged for my platform and I
must say that it is not too difficult when building only well tested
features for well tested architecture combination (C/C++ compiler i386
GNU/Linux -> i386 GNU/Linux).

Still the time and space required to build GCC is much larger than
that required for building grub. The OS X platform is somewhat exotic
because it uses different object format and non-gnu linker so it is
more likely there will be issues with building GCC. Since the time I
tried GCC is no longer self-containded but relies on additional
libraries that have to be installed separately so the user has to
compile several interdependent packages from source which certainly
requires more planning than just building a single package.

As for autoconf it is probably not required for building releases with
pre-generated scripts and may be already present on OS X.

The question here is if grub is supposed to be compatible with GNU
systems only (in which case we may as well throw it away because there
is no GNU system yet) or if it should follow the lead of software like
emacs or gcc and try to be compatible with as many different systems
as possible (within reason).

In the later case using an exotic feature like nested functions might
pose a problem on other systems as well and should be probably avoided
to improve portability in general.


Thanks

Michal

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Sat, Sep 05, 2009 at 01:47:52PM +0200, Yves Blusseau wrote:
>>
>> I assume you installed Apple's version of GCC.  Can you try with an  
>> official
>> GCC release?
>
> Yes, i have compiled on a true mac (Leopard 10.5.7) with the gcc-4.2.1  
> version.
>
> I have tried to compil with a mac port of gcc 4.4 but configure report  
> an error (about the linker):
>
> checking whether target compiler is working... no
> configure: error: cannot compile for the target
>
> and if i look into the config.log it's because it use the default apple 
> linker tool witch don't recognize some arguments:
>
> configure:5882: gcc-mp-4.4 -o conftest -Wall -W -Wshadow -Wpointer-arith 
> -Wmissing-prototypes  -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1 
> -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm -m32 - 
> fno-stack-protector -mno-stack-arg-probe -nostdlib -Wl,-- 
> defsym,___main=0x8100   -m32 conftest.c  >&5
> ld: unknown option: --defsym
> collect2: ld returned 1 exit status

Did you try with GNU binutils?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
> 
> Still the time and space required to build GCC is much larger than
> that required for building grub. The OS X platform is somewhat exotic
> because it uses different object format and non-gnu linker so it is
> more likely there will be issues with building GCC. Since the time I
> tried GCC is no longer self-containded but relies on additional
> libraries that have to be installed separately so the user has to
> compile several interdependent packages from source which certainly
> requires more planning than just building a single package.

Is there no simple mechanism for installing software on MacOS ?  E.g. on
Debian one would just use apt-get.  I heard about the Fink project,
although I haven't used it myself.

> The question here is if grub is supposed to be compatible with GNU
> systems only

We don't have this constraint.  It's fine to support non-GNU systems.  But
as a GNU project, I think it's normal that some of our dependencies are
GNU software.

Other non-GNU systems (e.g. Solaris) don't seem to have so much trouble.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

On Sat, Sep 5, 2009 at 10:31 PM, Robert Millan<rmh@aybabtu.com> wrote:
> On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
>>
>> Still the time and space required to build GCC is much larger than
>> that required for building grub. The OS X platform is somewhat exotic
>> because it uses different object format and non-gnu linker so it is
>> more likely there will be issues with building GCC. Since the time I
>> tried GCC is no longer self-containded but relies on additional
>> libraries that have to be installed separately so the user has to
>> compile several interdependent packages from source which certainly
>> requires more planning than just building a single package.
>
> Is there no simple mechanism for installing software on MacOS ?  E.g. on
> Debian one would just use apt-get.  I heard about the Fink project,
> although I haven't used it myself.
>
MacOSX has "software package" which is technically similar to .deb but
no repositories. Apple's gcc is shipped on installation DVDs and as
such is ready-available to the user.
From third-hand reports I have an information that macports package
GCC but not GNU binutils. I made the whole apple 's CC port in
response to a report by potential developper than he didn't succeed to
install required packages even after long fiddling with macports
Ruby and autoconf is shipped as a part of normal development tools
package (available on OSX install DVD among other places)
>> The question here is if grub is supposed to be compatible with GNU
>> systems only
>
> We don't have this constraint.  It's fine to support non-GNU systems.  But
> as a GNU project, I think it's normal that some of our dependencies are
> GNU software.
>
Yes but you can't force user to install more GNU than he wants. If
supporting Apple's CC gets in the way of developpement I'll say
ditching its support is a natural step. But I don't ask to hold back
any code nor to test Every build with Apple's CC or maintain its
support. Just accept simple fixes for it if it doesn't affect other
systems


-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]


Le 5 sept. 09 à 22:31, Robert Millan a écrit :

> On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
>>
>> Still the time and space required to build GCC is much larger than
>> that required for building grub. The OS X platform is somewhat exotic
>> because it uses different object format and non-gnu linker so it is
>> more likely there will be issues with building GCC. Since the time I
>> tried GCC is no longer self-containded but relies on additional
>> libraries that have to be installed separately so the user has to
>> compile several interdependent packages from source which certainly
>> requires more planning than just building a single package.
>
> Is there no simple mechanism for installing software on MacOS ?   
> E.g. on
> Debian one would just use apt-get.  I heard about the Fink project,
> although I haven't used it myself.

On MacOS you can install external program by compiling it with  
software like Fink or MacPorts (http://www.macports.org/)

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Sun, Sep 06, 2009 at 06:55:41AM +0200, Yves Blusseau wrote:
>
> Le 5 sept. 09 à 22:31, Robert Millan a écrit :
>
>> On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
>>>
>>> Still the time and space required to build GCC is much larger than
>>> that required for building grub. The OS X platform is somewhat exotic
>>> because it uses different object format and non-gnu linker so it is
>>> more likely there will be issues with building GCC. Since the time I
>>> tried GCC is no longer self-containded but relies on additional
>>> libraries that have to be installed separately so the user has to
>>> compile several interdependent packages from source which certainly
>>> requires more planning than just building a single package.
>>
>> Is there no simple mechanism for installing software on MacOS ?  E.g. 
>> on
>> Debian one would just use apt-get.  I heard about the Fink project,
>> although I haven't used it myself.
>
> On MacOS you can install external program by compiling it with software 
> like Fink or MacPorts (http://www.macports.org/)

I see that "gcc44" is listed there (as well as "apple-gcc42" for Apple's
version which we're already "aquainted" with).

So I take it that we can direct MacOS users to this repository, and they
would be able to install a working GCC from it?

The alternative would be to figure out the situation with Apple-GCC 4.2.  I
can ellaborate on that if you'd like.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 2249 bytes --]


Le 6 sept. 09 à 16:54, Robert Millan a écrit :

> On Sun, Sep 06, 2009 at 06:55:41AM +0200, Yves Blusseau wrote:
>>
>> Le 5 sept. 09 à 22:31, Robert Millan a écrit :
>>
>>> On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
>>>>
>>>> Still the time and space required to build GCC is much larger than
>>>> that required for building grub. The OS X platform is somewhat  
>>>> exotic
>>>> because it uses different object format and non-gnu linker so it is
>>>> more likely there will be issues with building GCC. Since the  
>>>> time I
>>>> tried GCC is no longer self-containded but relies on additional
>>>> libraries that have to be installed separately so the user has to
>>>> compile several interdependent packages from source which certainly
>>>> requires more planning than just building a single package.
>>>
>>> Is there no simple mechanism for installing software on MacOS ?   
>>> E.g.
>>> on
>>> Debian one would just use apt-get.  I heard about the Fink project,
>>> although I haven't used it myself.
>>
>> On MacOS you can install external program by compiling it with  
>> software
>> like Fink or MacPorts (http://www.macports.org/)
>
> I see that "gcc44" is listed there (as well as "apple-gcc42" for  
> Apple's
> version which we're already "aquainted" with).
>
> So I take it that we can direct MacOS users to this repository, and  
> they
> would be able to install a working GCC from it?

Look at my previous post:

I have tried to compil with a mac port of gcc 4.4 but configure report  
an error (about the linker):

checking whether target compiler is working... no
configure: error: cannot compile for the target

and if i look into the config.log it's because it use the default  
apple linker tool witch don't recognize some arguments:

configure:5882: gcc-mp-4.4 -o conftest -Wall -W -Wshadow -Wpointer- 
arith -Wmissing-prototypes  -Wundef -Wstrict-prototypes -g -Os -falign- 
jumps=1 -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm -m32 - 
fno-stack-protector -mno-stack-arg-probe -nostdlib -Wl,-- 
defsym,___main=0x8100   -m32 conftest.c  >&5
ld: unknown option: --defsym
collect2: ld returned 1 exit status


Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Vladimir 'phcoder' Serbinenko]

> checking whether target compiler is working... no
> configure: error: cannot compile for the target
>
> and if i look into the config.log it's because it use the default apple
> linker tool witch don't recognize some arguments:
>
> configure:5882: gcc-mp-4.4 -o conftest -Wall -W -Wshadow -Wpointer-arith
> -Wmissing-prototypes  -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1
> -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm -m32
> -fno-stack-protector -mno-stack-arg-probe -nostdlib
> -Wl,--defsym,___main=0x8100   -m32 conftest.c  >&5
> ld: unknown option: --defsym
> collect2: ld returned 1 exit status
>
The problem is my fault. The fixes I added for Apple port check for
Apple's CC whereas some of them should check for binutils. Can you
propose a simple way to check if gcc uses Apple's binutils?
>
> Regards,
> Yves Blusseau
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 1051 bytes --]


Le 6 sept. 09 à 19:17, Vladimir 'phcoder' Serbinenko a écrit :

>> checking whether target compiler is working... no
>> configure: error: cannot compile for the target
>>
>> and if i look into the config.log it's because it use the default  
>> apple
>> linker tool witch don't recognize some arguments:
>>
>> configure:5882: gcc-mp-4.4 -o conftest -Wall -W -Wshadow -Wpointer- 
>> arith
>> -Wmissing-prototypes  -Wundef -Wstrict-prototypes -g -Os -falign- 
>> jumps=1
>> -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm -m32
>> -fno-stack-protector -mno-stack-arg-probe -nostdlib
>> -Wl,--defsym,___main=0x8100   -m32 conftest.c  >&5
>> ld: unknown option: --defsym
>> collect2: ld returned 1 exit status
>>
> The problem is my fault. The fixes I added for Apple port check for
> Apple's CC whereas some of them should check for binutils. Can you
> propose a simple way to check if gcc uses Apple's binutils?

Yep i will try to find a way to compil with Mac Ports version of GCC  
on MacOSX

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 2400 bytes --]


Le 6 sept. 09 à 16:54, Robert Millan a écrit :

> On Sun, Sep 06, 2009 at 06:55:41AM +0200, Yves Blusseau wrote:
>>
>> Le 5 sept. 09 à 22:31, Robert Millan a écrit :
>>
>>> On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
>>>>
>>>> Still the time and space required to build GCC is much larger than
>>>> that required for building grub. The OS X platform is somewhat  
>>>> exotic
>>>> because it uses different object format and non-gnu linker so it is
>>>> more likely there will be issues with building GCC. Since the  
>>>> time I
>>>> tried GCC is no longer self-containded but relies on additional
>>>> libraries that have to be installed separately so the user has to
>>>> compile several interdependent packages from source which certainly
>>>> requires more planning than just building a single package.
>>>
>>> Is there no simple mechanism for installing software on MacOS ?   
>>> E.g.
>>> on
>>> Debian one would just use apt-get.  I heard about the Fink project,
>>> although I haven't used it myself.
>>
>> On MacOS you can install external program by compiling it with  
>> software
>> like Fink or MacPorts (http://www.macports.org/)
>
> I see that "gcc44" is listed there (as well as "apple-gcc42" for  
> Apple's
> version which we're already "aquainted" with).
>
> So I take it that we can direct MacOS users to this repository, and  
> they
> would be able to install a working GCC from it?

Bad news grub not compiled on a GCC 4.4.1 from MacPorts:

gcc-mp-4.4 -Iloader/i386 -I./loader/i386 -I. -I./include -I./include - 
Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing- 
prototypes                  -Wundef -Wstrict-prototypes -g -Os -falign- 
jumps=1 -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm - 
DAPPLE_CC=1 -m32 -fno-stack-protector -mno-stack-arg-probe -fno- 
builtin -mrtd -mregparm=3 -m32 -MD -c -o linux_mod-loader_i386_linux.o  
loader/i386/linux.c
20:16loader/i386/linux.c: In function 'grub_linux_boot':
20:16loader/i386/linux.c:546: error: can't find a register in class  
'BREG' while reloading 'asm'
20:16loader/i386/linux.c:546: error: 'asm' operand has impossible  
constraints
20:16make: * [linux_mod-loader_i386_linux.o] Error 1

MacPorts don't use specific patch to build gcc so i think the behavior  
is coded somewhere in the gcc source code.

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: Report: compil error on OSX for target=i386

[Felix Zielcke]

Am Sonntag, den 06.09.2009, 20:56 +0200 schrieb Yves Blusseau:
> Le 6 sept. 09 à 16:54, Robert Millan a écrit :
> 
> > On Sun, Sep 06, 2009 at 06:55:41AM +0200, Yves Blusseau wrote:
> >>
> >> Le 5 sept. 09 à 22:31, Robert Millan a écrit :
> >>
> >>> On Sat, Sep 05, 2009 at 03:17:58PM +0200, Michal Suchanek wrote:
> >>>>
> >>>> Still the time and space required to build GCC is much larger than
> >>>> that required for building grub. The OS X platform is somewhat  
> >>>> exotic
> >>>> because it uses different object format and non-gnu linker so it is
> >>>> more likely there will be issues with building GCC. Since the  
> >>>> time I
> >>>> tried GCC is no longer self-containded but relies on additional
> >>>> libraries that have to be installed separately so the user has to
> >>>> compile several interdependent packages from source which certainly
> >>>> requires more planning than just building a single package.
> >>>
> >>> Is there no simple mechanism for installing software on MacOS ?   
> >>> E.g.
> >>> on
> >>> Debian one would just use apt-get.  I heard about the Fink project,
> >>> although I haven't used it myself.
> >>
> >> On MacOS you can install external program by compiling it with  
> >> software
> >> like Fink or MacPorts (http://www.macports.org/)
> >
> > I see that "gcc44" is listed there (as well as "apple-gcc42" for  
> > Apple's
> > version which we're already "aquainted" with).
> >
> > So I take it that we can direct MacOS users to this repository, and  
> > they
> > would be able to install a working GCC from it?
> 
> Bad news grub not compiled on a GCC 4.4.1 from MacPorts:
> 
> gcc-mp-4.4 -Iloader/i386 -I./loader/i386 -I. -I./include -I./include - 
> Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing- 
> prototypes                  -Wundef -Wstrict-prototypes -g -Os -falign- 
> jumps=1 -falign-loops=1 -falign-functions=1 -fno-dwarf2-cfi-asm - 
> DAPPLE_CC=1 -m32 -fno-stack-protector -mno-stack-arg-probe -fno- 
> builtin -mrtd -mregparm=3 -m32 -MD -c -o linux_mod-loader_i386_linux.o  
> loader/i386/linux.c
> 20:16loader/i386/linux.c: In function 'grub_linux_boot':
> 20:16loader/i386/linux.c:546: error: can't find a register in class  
> 'BREG' while reloading 'asm'
> 20:16loader/i386/linux.c:546: error: 'asm' operand has impossible  
> constraints
> 20:16make: * [linux_mod-loader_i386_linux.o] Error 1
> 
> MacPorts don't use specific patch to build gcc so i think the behavior  
> is coded somewhere in the gcc source code.
> 

Exactly that line (well s/gcc-mp-4.4/gcc-4.4/) works fine with the
Debian gcc 4.4.1-3 which is actually a SVN snapshot from 20090822


-- 
Felix Zielcke
Proud Debian Maintainer

Re: Report: compil error on OSX for target=i386

[Robert Millan]

On Sun, Sep 06, 2009 at 08:56:59PM +0200, Yves Blusseau wrote:
>
> Bad news grub not compiled on a GCC 4.4.1 from MacPorts:
>
> gcc-mp-4.4 -Iloader/i386 -I./loader/i386 -I. -I./include -I./include - 
> Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes           
>        -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1 -falign-loops=1 
> -falign-functions=1 -fno-dwarf2-cfi-asm -DAPPLE_CC=1 -m32 
> -fno-stack-protector -mno-stack-arg-probe -fno-builtin -mrtd -mregparm=3 
> -m32 -MD -c -o linux_mod-loader_i386_linux.o loader/i386/linux.c
> 20:16loader/i386/linux.c: In function 'grub_linux_boot':
> 20:16loader/i386/linux.c:546: error: can't find a register in class  
> 'BREG' while reloading 'asm'
> 20:16loader/i386/linux.c:546: error: 'asm' operand has impossible  
> constraints
> 20:16make: * [linux_mod-loader_i386_linux.o] Error 1
>
> MacPorts don't use specific patch to build gcc so i think the behavior  
> is coded somewhere in the gcc source code.

I guess that's the implicit -fPIC you mentioned on IRC?

Does -fno-PIC help?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: Report: compil error on OSX for target=i386

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]


Le 8 sept. 09 à 16:41, Robert Millan a écrit :

> On Sun, Sep 06, 2009 at 08:56:59PM +0200, Yves Blusseau wrote:
>>
>> Bad news grub not compiled on a GCC 4.4.1 from MacPorts:
>>
>> gcc-mp-4.4 -Iloader/i386 -I./loader/i386 -I. -I./include -I./ 
>> include -
>> Wall -W  -Wall -W -Wshadow -Wpointer-arith -Wmissing-prototypes
>>       -Wundef -Wstrict-prototypes -g -Os -falign-jumps=1 -falign- 
>> loops=1
>> -falign-functions=1 -fno-dwarf2-cfi-asm -DAPPLE_CC=1 -m32
>> -fno-stack-protector -mno-stack-arg-probe -fno-builtin -mrtd - 
>> mregparm=3
>> -m32 -MD -c -o linux_mod-loader_i386_linux.o loader/i386/linux.c
>> 20:16loader/i386/linux.c: In function 'grub_linux_boot':
>> 20:16loader/i386/linux.c:546: error: can't find a register in class
>> 'BREG' while reloading 'asm'
>> 20:16loader/i386/linux.c:546: error: 'asm' operand has impossible
>> constraints
>> 20:16make: * [linux_mod-loader_i386_linux.o] Error 1
>>
>> MacPorts don't use specific patch to build gcc so i think the  
>> behavior
>> is coded somewhere in the gcc source code.
>
> I guess that's the implicit -fPIC you mentioned on IRC?
>
> Does -fno-PIC help?

Yes with -fno-PIC grub compile with gcc-mp-4.4 but do not generate a  
good boot.img and/or core.img:

http://gandalf.zetam.org/dropzone/Screenshot%202009-09-08%2019h%2037m%2007s.png

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]