Patch for cygwin: autoupdate and objdump

[Charles Wilson]

Working with one of the other cygwin maintainers who is repsonsible for 
about 1500 different cygwin packages, many of which use libtool but have 
not yet officially updated to libtool-2.2, we've found that the 
following patch is necessary.

(1) ensure that autoupdate does not modify behavior of configure with 
regards to time-of-libtool creation.  That is, when auto-updating, 
replace A[CM]_PROG_LIBTOOL with LT_INIT;LT_OUTPUT.

(2) Quoting:
> The AC_LIBTOOL_WIN32_DLL macro was supposed to be used in packages which
> built on Win32 platforms, in order to create DLLs.  This macro tested
> for as, dlltool, and objdump.  The latter is used in the file_magic test
> to determine if a .a is a static or import library.

Of course, that now should be LT_INIT([ ... win32-dll ... ])

> In 1.5 libtool worked anyway without it, because among other variables,
> OBJDUMP was given a "sane default" near the beginning of libtool.m4 and
> was always exported, and AS and DLLTOOL weren't needed.

So, many packages that were "ported" to win32 (or, just to 
cygwin-on-win32), did not actually specify AC_LIBTOOL_WIN32_DLL / 
LT_INIT([win32-dll]).  But they worked anyway, because the only thing 
they REALLY needed was $OBJDUMP.

> But in 2.2, the "sane defaults" have been minimized, and OBJDUMP is no
> longer defined by default, so without the win32-dll arg to LT_INIT (or
> the AC_LIBTOOL_WIN32_DLL compat macro), libtool refuses to link shared
> libs against non-libtoolized shared libs, because the file_magic test on
> the implib fails due to an undefined OBJDUMP variable.  Assuring that
> OBJDUMP is defined is therefore necessary for compatibility with
> previous behaviour.

You can say "but you ought to modify your configure.ac to specify 
AC_LIBTOOL_WIN32_DLL / LT_INIT([win32-dll])" 'till you're blue in the 
face, but many existing packages -- those that exported no data items -- 
worked ok with libtool-1.5 and did build shared [*], and now they don't. 
That's a regression.

[*] side note: ------
the documentation on win32-dll is confusing, as also mentioned in a 
different thread. It seems to imply that you should only use it if 
you've done explicit declspec(dllimport) modifications to your source. 
And then it lies and says it won't build DLLs at all unless you specify 
it. But in 1.5, this was not true because you could "get away with" the 
default $OBJDUMP value, and if you had no data exports, it WOULD 
successfully build a DLL.

The following sentence should be modified as:
"Usually this means that any library data items are..."
"Usually this means that @emph{data} items, if any are exposed by the 
library interface, are..."

This sentence should just be removed:
"If this macro is not used, libtool will assume that the package 
libraries are not dll clean and will build only static libraries on 
win32 hosts."
------ end side note

It seems this was referred to in another thread on bug-libtool:
http://lists.gnu.org/archive/html/bug-libtool/2008-03/msg00119.html
I *think* the attached patch also solves the 'make sure to define 
OBJDUMP only after AC_CANONICAL_HOST' problem mentioned there.

> Not only that, but this may fix another possible bug on Linux ELF
> systems, as there is a test on that platform (line 2461 after the patch)
> which uses OBJDUMP, which I don't see where it would have been defined. 

Yep, looks like previously on Linux-ELF, OBJDUMP always used the default 
value of 'objdump'. Now there is no default...

cygwin's libtool-2.2 package is currently shipping with this patch.


2008-04-19  Charles Wilson  <...>
            Yaakov Selkowitz  <...>

        * libltdl/m4/libtool.m4 (_LT_DECL_OBJDUMP): new macro ensures
        that $OBJDUMP is always defined sanely.
        (_LT_SYS_DYNAMIC_LINKER): call it.
        (_LT_CHECK_MAGIC_METHOD): call it.
        (AU_DEFUN[AC_PROG_LIBTOOL]): replace AU_ALIAS[AC_PROG_LIBTOOL];
        call both LT_INIT and LT_OUTPUT. Warn user to remove LT_OUTPUT
        if not necessary for their package.
        (AU_ALIAS[AM_PROG_LIBTOOL]): direct to AC_PROG_LIBTOOL above,
        not LT_INIT.

--
Chuck



diff -urN origsrc/libtool-2.2.2/libltdl/m4/libtool.m4 
src/libtool-2.2.2/libltdl/m4/libtool.m4
--- origsrc/libtool-2.2.2/libltdl/m4/libtool.m4 2008-04-01 14:20:04.000000000 
-0400
+++ src/libtool-2.2.2/libltdl/m4/libtool.m4     2008-04-14 01:29:38.750000000 
-0400
@@ -99,8 +99,15 @@
 ])# LT_INIT
 
 # Old names:
-AU_ALIAS([AC_PROG_LIBTOOL], [LT_INIT])
-AU_ALIAS([AM_PROG_LIBTOOL], [LT_INIT])
+AU_DEFUN([AC_PROG_LIBTOOL],
+[LT_INIT
+LT_OUTPUT
+AC_DIAGNOSE([obsolete],
+[$0: Remove this warning and the call to LT_OUTPUT if you do not need
+libtool to exist before AC_OUTPUT.])
+])
+
+AU_ALIAS([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL])
 dnl aclocal-1.4 backwards compatibility:
 dnl AC_DEFUN([AC_PROG_LIBTOOL], [])
 dnl AC_DEFUN([AM_PROG_LIBTOOL], [])
@@ -2026,6 +2033,7 @@
 [AC_REQUIRE([AC_CANONICAL_HOST])dnl
 m4_require([_LT_DECL_EGREP])dnl
 m4_require([_LT_FILEUTILS_DEFAULTS])dnl
+m4_require([_LT_DECL_OBJDUMP])dnl
 m4_require([_LT_DECL_SED])dnl
 AC_MSG_CHECKING([dynamic linker characteristics])
 m4_if([$1],
@@ -2947,6 +2955,7 @@
 #  -- PORTME fill in with the dynamic library characteristics
 m4_defun([_LT_CHECK_MAGIC_METHOD],
 [m4_require([_LT_DECL_EGREP])
+m4_require([_LT_DECL_OBJDUMP])
 AC_CACHE_CHECK([how to recognize dependent libraries],
 lt_cv_deplibs_check_method,
 [lt_cv_file_magic_cmd='$MAGIC_CMD'
@@ -6961,6 +6970,18 @@
 ])
 
 
+# _LT_DECL_OBJDUMP
+# --------------
+# If we don't have a new enough Autoconf to choose the best objdump
+# available, choose the one first in the user's PATH.
+m4_defun([_LT_DECL_OBJDUMP],
+[AC_CHECK_TOOL(OBJDUMP, objdump, false)
+test -z "$OBJDUMP" && OBJDUMP=objdump
+_LT_DECL([], [OBJDUMP], [1], [An object symbol dumper])
+AC_SUBST([OBJDUMP])
+])
+
+
 # _LT_DECL_SED
 # ------------
 # Check for a fully-functional sed program, that truncates