Patchwork mingw32: Only link against libiberty if required

login
register
mail settings
Submitter Jan Kiszka
Date July 24, 2011, 10:12 a.m.
Message ID <4E2BEFFF.5050000@web.de>
Download mbox | patch
Permalink /patch/106509/
State New
Headers show

Comments

Jan Kiszka - July 24, 2011, 10:12 a.m.
From: Jan Kiszka <jan.kiszka@siemens.com>

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 <jan.kiszka@siemens.com>
---
 configure |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)
Stefan Weil - July 24, 2011, 11:04 a.m.
Am 24.07.2011 12:12, schrieb Jan Kiszka:
> From: Jan Kiszka <jan.kiszka@siemens.com>
>
> 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 <jan.kiszka@siemens.com>
> ---
> 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.

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.

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.

Kind regards,
Stefan Weil
Jan Kiszka - July 24, 2011, 11:48 a.m.
On 2011-07-24 13:04, Stefan Weil wrote:
> Am 24.07.2011 12:12, schrieb Jan Kiszka:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> 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 <jan.kiszka@siemens.com>
>> ---
>> 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

Patch

diff --git a/configure b/configure
index 6911c3b..42effb9 100755
--- a/configure
+++ b/configure
@@ -481,7 +481,16 @@  if test "$mingw32" = "yes" ; then
   QEMU_CFLAGS="-DWIN32_LEAN_AND_MEAN -DWINVER=0x501 $QEMU_CFLAGS"
   # enable C99/POSIX format strings (needs mingw32-runtime 3.15 or later)
   QEMU_CFLAGS="-D__USE_MINGW_ANSI_STDIO=1 $QEMU_CFLAGS"
-  LIBS="-lwinmm -lws2_32 -liberty -liphlpapi $LIBS"
+  # check need for -liberty (getopt on w64)
+  cat > $TMPC << EOF
+#include <unistd.h>
+int main(void) { return getopt(0, NULL, NULL); }
+EOF
+  if compile_prog "" "" ; then
+    LIBS="-lwinmm -lws2_32 -liphlpapi $LIBS"
+  else
+    LIBS="-lwinmm -lws2_32 -liberty -liphlpapi $LIBS"
+  fi
   prefix="c:/Program Files/Qemu"
   mandir="\${prefix}"
   datadir="\${prefix}"