Re: [Qemu-devel] [PATCH] mingw32: Only link against libiberty if required

[Jan Kiszka]

On 2011-07-24 13:04, Stefan Weil wrote:
> Am 24.07.2011 12:12, schrieb Jan Kiszka:
>> From: Jan Kiszka <address@hidden>
>>
>> Not all (didn't find any) mingw32 cross-toolchains ship a binutils-devel
>> package, thus lack libiberty.a. According to 08f3896a, -liberty is only
>> needed for getopt when building for 64 bit. Test for the availability
>> of a getopt implementation and only pull in libiberty when linking
>> without it failed.
>>
>> Signed-off-by: Jan Kiszka <address@hidden>
>> ---
>> configure | 11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletions(-)
> 
> Hi,
> 
> I also had problems with some MinGW build environments
> which don't provide libiberty.a. Debian's gcc-mingw32
> cross toolchain which I normally use provides it.
> 
> libiberty.a not only includes getopt(), but also several other
> useful functions. Especially ffs() is needed for compilations
> without optimization and was the main reason for commit 08f3896a.
> ffs() normally is inline code, and an implementation in
> QEMU code was removed after 08f3896a.
> 
> So at least for Debian cross compilation without optimization,
> your patch will break 32 bit builds because ffs() would be missing.
> 
> The latest commits to QEMU git master added a lot of new requirements
> for MinGW builds (glib ...). Maybe some of these also require
> libiberty.a. Therefore I suggest to wait until git master is
> working again with MinGW32.

Builds fine here (except for the usual warnings) with Blue's fix for
qemu-char.c. Same is true when passing in CFLAGS=-O0.

> 
> Could you describe your build requirements in the QEMU Wiki
> (http://wiki.qemu.org/Hosts/W32)? Then we can see better how
> the different needs of native builds and cross builds with
> different distributions can be met, both for w32 and w64.

Done.

> 
> If there are MinGW (cross) build environments which really
> don't need libiberty.a, we could modify the check to add
> linker option -liberty only when the library is available.

That was my original idea, at least for 32-bit builds (my toolchain
carries 'w64' in its name, but only support w32). How to express this best?

Jan

signature.asc
Description: OpenPGP digital signature