Am 15.02.2013 20:40, schrieb Andreas Färber:
> Am 15.02.2013 19:29, schrieb Jacob Kroon:
>> On Fri, Feb 15, 2013 at 7:03 PM, Andreas Färber <afaer...@suse.de> wrote:
>>> Am 06.02.2013 14:12, schrieb Jacob Kroon:
>>>> I'm trying to cross-build qemu for win64 on a Fedora 18/x86_64 system,
>>>> using all the necessary mingw64 packages from Fedora. Using latest
>>>> qemu from git (5f876756c57c15f5e14d4136fc432b74f05f082b), I get an
>>>> error when linking "qemu-img.exe":
>>> Has this been resolved in the meantime? MinGW64 cross-build of my patch
>>> queue works fine.
>> I tried again with latest from git,
>> 571f65ec20fbcb991d7bce51787248ab9d325e3f, I still get the linking
>> errors though.
>>
>> The configure-script command-line I use is:
>>
>> ./configure --cross-prefix=x86_64-w64-mingw32- --disable-guest-agent
>> --disable-vnc --disable-werror --enable-debug
>> --target-list=i386-softmmu
>>
>> I'm on a Fedora 18 system, updated with latest packages.
> Okay, so I can reproduce it now by adding --enable-debug:
> .../configure --cross-prefix=x86_64-w64-mingw32- --enable-debug
>
> LINK arm-softmmu/qemu-system-armw.exe
> ../block.o: In function `bdrv_set_dirty_tracking':
> /home/andreas/QEMU/qemu-cpu/block.c:4316: undefined reference to `ffs'
> ../block/qcow2.o: In function `qcow2_create2':
> /home/andreas/QEMU/qemu-cpu/block/qcow2.c:1184: undefined reference to `ffs'
> ../block/qed.o: In function `bdrv_qed_open':
> /home/andreas/QEMU/qemu-cpu/block/qed.c:429: undefined reference to `ffs'
> /home/andreas/QEMU/qemu-cpu/block/qed.c:431: undefined reference to `ffs'
> ../hw/bt-sdp.o: In function `sdp_service_record_build':
> /home/andreas/QEMU/qemu-cpu/hw/bt-sdp.c:710: undefined reference to `ffs'
> ../hw/max7310.o:/home/andreas/QEMU/qemu-cpu/hw/max7310.c:94: more
> undefined references to `ffs' follow
> collect2: error: ld returned 1 exit status
> make[1]: *** [qemu-system-armw.exe] Fehler 1
> make: *** [subdir-arm-softmmu] Fehler 2
>
> Jacob, for now just drop --enable-debug from your command line or try
> tweaking --extra-cflags with some higher -O optimization option.
>
> Paolo, Stefan, any ideas how to fix?
>
> Andreas
Hi Jacob,
earlier versions of QEMU provided an implementation of ffs()
because it was needed for w32 compilations without optimisation.
Later w32 used libiberty.a which provides ffs(). w64 never needed
the ffs() implementation, so I removed it in commit
57a8821bc6e4457230075a5c8da5f8a083889686.
In my builds (w32 and w64, Debian / Ubuntu Linux cross and native)
I don't get an unresolvedsymbol ffs.
It looks like most (but not all) versions of gcc emit built-in code
for ffs() even for compilations without optimisation. I have to provide
additional compiler options (e.g. -fno-builtin-ffs) to get a real
function call.
Only then I get the linker errors which you see.
Obviously your compiler behaves different (or did you add extra
compiler options?).
Try this short test.c code:
int ffs(unsigned n);
int main(int argc, char *argv[])
{
return ffs(argc);
}
On Debian, I compiled and tested like this:
amd64-mingw32msvc-gcc -c -g -O0 test.c
amd64-mingw32msvc-nm test.o
There is no ffs function call in the resulting binary.
If your compiler creates a function call, we have to know
why and whether there is a simple rule which versions of
gcc behave like that. If there is no simple rule, we need
a configure check.
Regards,
Stefan W.
