[Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Bartlomiej Celary]

Hi,
I have recently updated my git snapshot and had 2 problems:

1. There is no strnlen function in MINGW (not sure if it has been
added recently as I might be using an outdated version...)

2. I was not able to link multiboot.bin using mingw:

for d in pc-bios/optionrom; do \
make -C $d || exit 1 ; \
        done
make[1]: Entering directory `/home/abc024/work/qemu/pc-bios/optionrom'
gcc -o signrom -g -Wall signrom.c
gcc -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer
-fno-builtin -I/home/abc024/work/qemu -o multiboot.o -c multiboot.S
ld --oformat binary -Ttext 0 -o multiboot.img multiboot.o
D:\mingw\bin\ld.exe: cannot perform PE operations on non PE output
file 'multiboot.img'.
make[1]: *** [multiboot.img] Error 1
rm multiboot.o
make[1]: Leaving directory `/home/abc024/work/qemu/pc-bios/optionrom'
make: *** [roms] Error 1

And it looks that this workaround did the trick:

diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
old mode 100644
new mode 100755
index c4a6f42..f414eba
--- a/pc-bios/optionrom/Makefile
+++ b/pc-bios/optionrom/Makefile
@@ -34,8 +34,14 @@ build-all: multiboot.bin
 %.o: %.S
        $(CC) $(CFLAGS) -o $@ -c $<

-%.img: %.o
-       $(LD) --oformat binary -Ttext 0 -o $@ $<
+%.img: %.out
+       $(OBJCOPY) -O binary -j .text $< $@
+
+%.out: %.o
+       $(LD) -Ttext 0 -e _start -s -o $@ $<

 %.bin: %.img signrom
        ./signrom $< $@

Obviously objcopy needs to be defined in the config.mak file.

Regards,
Bartek Celary

Re: [Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Anthony Liguori]

Bartlomiej Celary wrote:
> Hi,
> I have recently updated my git snapshot and had 2 problems:
>   

Thanks for the report.

> 1. There is no strnlen function in MINGW (not sure if it has been
> added recently as I might be using an outdated version...)
>   

That should be easy enough to fix.  Can you send a patch?

> 2. I was not able to link multiboot.bin using mingw:
>
> for d in pc-bios/optionrom; do \
> make -C $d || exit 1 ; \
>         done
> make[1]: Entering directory `/home/abc024/work/qemu/pc-bios/optionrom'
> gcc -o signrom -g -Wall signrom.c
> gcc -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer
> -fno-builtin -I/home/abc024/work/qemu -o multiboot.o -c multiboot.S
> ld --oformat binary -Ttext 0 -o multiboot.img multiboot.o
> D:\mingw\bin\ld.exe: cannot perform PE operations on non PE output
> file 'multiboot.img'.
> make[1]: *** [multiboot.img] Error 1
> rm multiboot.o
> make[1]: Leaving directory `/home/abc024/work/qemu/pc-bios/optionrom'
> make: *** [roms] Error 1
>
> And it looks that this workaround did the trick:
>
> diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
> old mode 100644
> new mode 100755
> index c4a6f42..f414eba
> --- a/pc-bios/optionrom/Makefile
> +++ b/pc-bios/optionrom/Makefile
> @@ -34,8 +34,14 @@ build-all: multiboot.bin
>  %.o: %.S
>         $(CC) $(CFLAGS) -o $@ -c $<
>
> -%.img: %.o
> -       $(LD) --oformat binary -Ttext 0 -o $@ $<
> +%.img: %.out
> +       $(OBJCOPY) -O binary -j .text $< $@
> +
> +%.out: %.o
> +       $(LD) -Ttext 0 -e _start -s -o $@ $<
>
>  %.bin: %.img signrom
>         ./signrom $< $@
>
> Obviously objcopy needs to be defined in the config.mak file.
>   

I'm not sure I understand why this works, but if you resubmit the patch 
with a Signed-off-by, we can apply it.

It's unfortunate that we need to do the signrom step now that I think 
about it as it's bad for cross-compilation.  Maybe we should sign 
anything without a checksum when doing option rom loading.  What do you 
think Alex?

Regards,

Anthony Liguori

> Regards,
> Bartek Celary
>
>
>   

Re: [Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Alexander Graf]

On 01.07.2009, at 15:24, Anthony Liguori wrote:

> Bartlomiej Celary wrote:
>> Hi,
>> I have recently updated my git snapshot and had 2 problems:
>>
>
> Thanks for the report.
>
>> 1. There is no strnlen function in MINGW (not sure if it has been
>> added recently as I might be using an outdated version...)
>>
>
> That should be easy enough to fix.  Can you send a patch?
>
>> 2. I was not able to link multiboot.bin using mingw:
>>
>> for d in pc-bios/optionrom; do \
>> make -C $d || exit 1 ; \
>>        done
>> make[1]: Entering directory `/home/abc024/work/qemu/pc-bios/ 
>> optionrom'
>> gcc -o signrom -g -Wall signrom.c
>> gcc -Wall -Wstrict-prototypes -Werror -fomit-frame-pointer
>> -fno-builtin -I/home/abc024/work/qemu -o multiboot.o -c multiboot.S
>> ld --oformat binary -Ttext 0 -o multiboot.img multiboot.o
>> D:\mingw\bin\ld.exe: cannot perform PE operations on non PE output
>> file 'multiboot.img'.
>> make[1]: *** [multiboot.img] Error 1
>> rm multiboot.o
>> make[1]: Leaving directory `/home/abc024/work/qemu/pc-bios/optionrom'
>> make: *** [roms] Error 1
>>
>> And it looks that this workaround did the trick:
>>
>> diff --git a/pc-bios/optionrom/Makefile b/pc-bios/optionrom/Makefile
>> old mode 100644
>> new mode 100755
>> index c4a6f42..f414eba
>> --- a/pc-bios/optionrom/Makefile
>> +++ b/pc-bios/optionrom/Makefile
>> @@ -34,8 +34,14 @@ build-all: multiboot.bin
>> %.o: %.S
>>        $(CC) $(CFLAGS) -o $@ -c $<
>>
>> -%.img: %.o
>> -       $(LD) --oformat binary -Ttext 0 -o $@ $<
>> +%.img: %.out
>> +       $(OBJCOPY) -O binary -j .text $< $@
>> +
>> +%.out: %.o
>> +       $(LD) -Ttext 0 -e _start -s -o $@ $<
>>
>> %.bin: %.img signrom
>>        ./signrom $< $@
>>
>> Obviously objcopy needs to be defined in the config.mak file.
>>
>
> I'm not sure I understand why this works, but if you resubmit the  
> patch with a Signed-off-by, we can apply it.
>
> It's unfortunate that we need to do the signrom step now that I  
> think about it as it's bad for cross-compilation.  Maybe we should  
> sign anything without a checksum when doing option rom loading.   
> What do you think Alex?

Why can't we just exclude mingw from building option roms? Let's just  
treat it like any non-x86 platform, so it takes the binary blobs.

Alex

Re: [Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Anthony Liguori]

Alexander Graf wrote:
> Why can't we just exclude mingw from building option roms? Let's just 
> treat it like any non-x86 platform, so it takes the binary blobs.

The signrom problem is independent on mingw32.  This makefile is doing 
something that the rest of the build system is careful not to do: 
compile a binary and run it as part of the build process.

That's why hxtool is not written in C.

Regards,

Anthony Liguori

> Alex
>

Re: [Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Alexander Graf]

On 01.07.2009, at 17:52, Anthony Liguori wrote:

> Alexander Graf wrote:
>> Why can't we just exclude mingw from building option roms? Let's  
>> just treat it like any non-x86 platform, so it takes the binary  
>> blobs.
>
> The signrom problem is independent on mingw32.  This makefile is  
> doing something that the rest of the build system is careful not to  
> do: compile a binary and run it as part of the build process.
>
> That's why hxtool is not written in C.

Well, the optionrom directory is a first of its kind: Full source to a  
binary blob.
So would you prefer to have signrom be in sh? :-)

Maybe I could come up with a version in brainfuck though ... hum

Alex

Re: [Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Bartlomiej Celary]

Hi,
Just tried latest pull from git and noticed the "cannot perform PE
operations on non PE output file 'multiboot.img'." error.

Is there any agreement on how to fix the linker issue under mingw?

Thanks,
Bartek Celary

2009/7/1 Alexander Graf <agraf@suse.de>:
>
> On 01.07.2009, at 17:52, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>>
>>> Why can't we just exclude mingw from building option roms? Let's just
>>> treat it like any non-x86 platform, so it takes the binary blobs.
>>
>> The signrom problem is independent on mingw32.  This makefile is doing
>> something that the rest of the build system is careful not to do: compile a
>> binary and run it as part of the build process.
>>
>> That's why hxtool is not written in C.
>
> Well, the optionrom directory is a first of its kind: Full source to a
> binary blob.
> So would you prefer to have signrom be in sh? :-)
>
> Maybe I could come up with a version in brainfuck though ... hum
>
> Alex
>
>

Re: [Qemu-devel] MINGW: Unable to link multiboot.img + strnlen missing

[Anthony Liguori]

Bartlomiej Celary wrote:
> Hi,
> Just tried latest pull from git and noticed the "cannot perform PE
> operations on non PE output file 'multiboot.img'." error.
>   

Someone posted a snippet in a thread but I can't find it.  If someone 
posts a top level patch, I'll apply it.

Regards,

Anthony Liguori

> Is there any agreement on how to fix the linker issue under mingw?
>
> Thanks,
> Bartek Celary
>
> 2009/7/1 Alexander Graf <agraf@suse.de>:
>   
>> On 01.07.2009, at 17:52, Anthony Liguori wrote:
>>
>>     
>>> Alexander Graf wrote:
>>>       
>>>> Why can't we just exclude mingw from building option roms? Let's just
>>>> treat it like any non-x86 platform, so it takes the binary blobs.
>>>>         
>>> The signrom problem is independent on mingw32.  This makefile is doing
>>> something that the rest of the build system is careful not to do: compile a
>>> binary and run it as part of the build process.
>>>
>>> That's why hxtool is not written in C.
>>>       
>> Well, the optionrom directory is a first of its kind: Full source to a
>> binary blob.
>> So would you prefer to have signrom be in sh? :-)
>>
>> Maybe I could come up with a version in brainfuck though ... hum
>>
>> Alex
>>
>>
>>     

[Qemu-devel] [PATCH] Win32: Fix build (no strnlen)

[Stefan Weil]

strnlen is a GNU extension which is missing in mingw32
and perhaps other build environments.

So we should avoid it and replace it by standard functions.

Signed-off-by: Stefan Weil <weil@mail.berlios.de>
---
 block.c |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/block.c b/block.c
index c66c031..79b3313 100644
--- a/block.c
+++ b/block.c
@@ -225,9 +225,14 @@ static BlockDriver *find_protocol(const char *filename)
 {
     BlockDriver *drv1;
     char protocol[128];
-    int len = strnlen(filename, 127)+1;
+    int len;
     const char *p;
 
+    len = strlen(filename) + 1;
+    if (len > sizeof(protocol)) {
+      len = sizeof(protocol);
+    }
+
 #ifdef _WIN32
     if (is_windows_drive(filename) ||
         is_windows_drive_prefix(filename))
-- 
1.5.6.5

[Qemu-devel] Re: [PATCH] Win32: Fix build (no strnlen)

[Consul]

Stefan Weil wrote:
> strnlen is a GNU extension which is missing in mingw32
> and perhaps other build environments.
> 
> So we should avoid it and replace it by standard functions.
> 
> Signed-off-by: Stefan Weil <weil@mail.berlios.de>
> ---
>  block.c |    7 ++++++-
>  1 files changed, 6 insertions(+), 1 deletions(-)
> 
> diff --git a/block.c b/block.c
> index c66c031..79b3313 100644
> --- a/block.c
> +++ b/block.c
> @@ -225,9 +225,14 @@ static BlockDriver *find_protocol(const char *filename)
>  {
>      BlockDriver *drv1;
>      char protocol[128];
> -    int len = strnlen(filename, 127)+1;
> +    int len;
>      const char *p;
>  
> +    len = strlen(filename) + 1;
> +    if (len > sizeof(protocol)) {
> +      len = sizeof(protocol);
> +    }
> +
>  #ifdef _WIN32
>      if (is_windows_drive(filename) ||
>          is_windows_drive_prefix(filename))

Or something like this?
#ifdef __MINGW32__
size_t strnlen (const char *string, size_t maxlen)
{
   const char *end = memchr (string, '\0', maxlen);
   return end ? (size_t) (end - string) : maxlen;
};
#endif

[Qemu-devel] (no subject)

[G 3]

> Stefan Weil wrote:
>
>     strnlen is a GNU extension which is missing in mingw32
>     and perhaps other build environments.
>
>
>     So we should avoid it and replace it by standard functions.
>
>
>     Signed-off-by: Stefan Weil <address@hidden>
>     ---
>      block.c |    7 ++++++-
>      1 files changed, 6 insertions(+), 1 deletions(-)
>
>
>     diff --git a/block.c b/block.c
>     index c66c031..79b3313 100644
>     --- a/block.c
>     +++ b/block.c
>     @@ -225,9 +225,14 @@ static BlockDriver *find_protocol(const char 
> *filename)
>     {
>     BlockDriver *drv1;
>     char protocol[128];
>     - int len = strnlen(filename, 127)+1;
>     + int len;
>     const char *p;
>     + len = strlen(filename) + 1;
>     + if (len > sizeof(protocol)) {
>     + len = sizeof(protocol);
>     + }
>     +
>     #ifdef _WIN32
>     if (is_windows_drive(filename) ||
>     is_windows_drive_prefix(filename))
>
>
> Or something like this?
> #ifdef __MINGW32__
> size_t strnlen (const char *string, size_t maxlen)
> {
>   const char *end = memchr (string, '\0', maxlen);
>   return end ? (size_t) (end - string) : maxlen;
> };
> #endif

block.c doesn't compile on Mac OS 10.3. I second the notion of removing 
strnlen.

[Qemu-devel] Re: [PATCH] Win32: Fix build (no strnlen)

[G 3]

On Jul 1, 2009, at 5:26 PM, G 3 wrote:

> Stefan Weil wrote:
>
>     strnlen is a GNU extension which is missing in mingw32
>     and perhaps other build environments.
>
>
>     So we should avoid it and replace it by standard functions.
>
>
>     Signed-off-by: Stefan Weil <address@hidden>
>     ---
>      block.c |    7 ++++++-
>      1 files changed, 6 insertions(+), 1 deletions(-)
>
>
>     diff --git a/block.c b/block.c
>     index c66c031..79b3313 100644
>     --- a/block.c
>     +++ b/block.c
>     @@ -225,9 +225,14 @@ static BlockDriver *find_protocol(const char 
> *filename)
>     {
>     BlockDriver *drv1;
>     char protocol[128];
>     - int len = strnlen(filename, 127)+1;
>     + int len;
>     const char *p;
>     + len = strlen(filename) + 1;
>     + if (len > sizeof(protocol)) {
>     + len = sizeof(protocol);
>     + }
>     +
>     #ifdef _WIN32
>     if (is_windows_drive(filename) ||
>     is_windows_drive_prefix(filename))
>
>
> Or something like this?
> #ifdef __MINGW32__
> size_t strnlen (const char *string, size_t maxlen)
> {
>   const char *end = memchr (string, '\0', maxlen);
>   return end ? (size_t) (end - string) : maxlen;
> };
> #endif

block.c doesn't compile on Mac OS 10.3. I second the notion of removing 
strnlen.

Sorry but I forgot the subject in the last email.