Re: mingw64

From: Peter Rosin <peda(at)lysator(dot)liu(dot)se>
To: MinGW Users List <mingw-users(at)lists(dot)sourceforge(dot)net>, "mingw-w64-public(at)lists(dot)sourceforge(dot)net" <mingw-w64-public(at)lists(dot)sourceforge(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: mingw64
Date: 2011-02-14 08:14:03
Message-ID: 4D58E44B.6090204@lysator.liu.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Den 2011-02-12 11:10 skrev Ralf Wildenhues:
> Hello, and sorry for the delay,
>
> * Peter Rosin wrote on Sat, Jan 29, 2011 at 02:26:24PM CET:
>> Or is plain 'ar' used somewhere instead of 'x86_64-w64-mingw32-ar'?
>
> Automake outputs 'AR = ar' in Makefile.in for rules creating old
> libraries iff neither AC_PROG_LIBTOOL nor another method to define
> AR correctly is used in configure.ac.
>
> So this issue concerns packages using Automake but not using Libtool.
>
> I figured with AM_PROG_AR eventually being needed anyway that would fix
> this in one go ...
>
> A good workaround, as already mentioned, is to use this in configure.ac:
> AC_CHECK_TOOL([AR], [ar], [false])

I just cannot understand why the workaround isn't always working in
this case.

There was a log posted with this in it
(in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02697.php)

...
configure:5962: checking for x86_64-w64-mingw32-ranlib
configure:5978: found /mingw/bin/x86_64-w64-mingw32-ranlib
configure:5989: result: x86_64-w64-mingw32-ranlib
configure:6055: checking for x86_64-w64-mingw32-strip
configure:6071: found /mingw/bin/x86_64-w64-mingw32-strip
configure:6082: result: x86_64-w64-mingw32-strip
configure:6145: checking whether it is possible to strip libraries
configure:6150: result: yes
configure:6164: checking for x86_64-w64-mingw32-ar
configure:6180: found /mingw/bin/x86_64-w64-mingw32-ar
configure:6191: result: x86_64-w64-mingw32-ar
configure:6257: checking for x86_64-w64-mingw32-dlltool
configure:6273: found /mingw/bin/x86_64-w64-mingw32-dlltool
configure:6284: result: x86_64-w64-mingw32-dlltool
configure:6349: checking for x86_64-w64-mingw32-dllwrap
configure:6365: found /mingw/bin/x86_64-w64-mingw32-dllwrap
configure:6376: result: x86_64-w64-mingw32-dllwrap
configure:6441: checking for x86_64-w64-mingw32-windres
configure:6457: found /mingw/bin/x86_64-w64-mingw32-windres
configure:6468: result: x86_64-w64-mingw32-windres
...

Which seem to match this snippet from configure.in:

...
AC_PROG_RANLIB
PGAC_CHECK_STRIP
AC_CHECK_TOOL(AR, ar, ar)
if test "$PORTNAME" = "win32"; then
AC_CHECK_TOOL(DLLTOOL, dlltool, dlltool)
AC_CHECK_TOOL(DLLWRAP, dllwrap, dllwrap)
AC_CHECK_TOOL(WINDRES, windres, windres)
fi
...

Sure, AC_CHECK_TOOL has under-quoted arguments and the last argument is
'ar' instead of 'false'. But that shouldn't really matter here. (Or
does it?)

Still, elsewhere in the thread there's a report about the wrong ar being
used.
(in http://archives.postgresql.org/pgsql-hackers/2011-01/msg02713.php)

Sure, the configure log and the "wrong ar"-report are not from the same
person, but the configure script should be the same for everybody (git
log hints that this part of configure has been stable for a couple of
years).

It just doesn't add up.

Cheers,
Peter

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Markus Wanner 2011-02-14 08:39:22 Re: Debian readline/libedit breakage
Previous Message Scott Marlowe 2011-02-14 07:01:37 Re: Why we don't want hints