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
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 |