Charles Wilson wrote:
The one remaining niggle is this: you *must* specify -no-undefined, or libtool won't even attempt to build a DLL.
I agree.
Isn't there a method in autoconf to define the macro as deprecated so that a warning is issued?
But anyway, -no-undefined is a whole separate issue. As far as AC_LIBTOOL_WIN32_DLL, from the cygwin perspective it can be killed. However, given that there are a lot of projects out there that probably have it in their configure.in's already, perhaps you should leave a dummy (empty) definition? Or is that not kosher libtool procedure?
Ah yes:
File: autoconf.info, Node: Obsoleting Macros, Next: Coding Style, Prev: Depe\
ndencies Between Macros, Up: Writing Autoconf Macros
Obsoleting Macros
=================
Configuration and portability technology has evolved over the years.
Often better ways of solving a particular problem are developed, or
ad-hoc approaches are systematized. This process has occurred in many
parts of Autoconf. One result is that some of the macros are now
considered "obsolete"; they still work, but are no longer considered
the best thing to do, hence they should be replaced with more modern
macros. Ideally, `autoupdate' should substitute the old macro calls
with their modern implementation.
Autoconf provides a simple means to obsolete a macro.
- Macro: AU_DEFUN (OLD-MACRO, IMPLEMENTATION, [MESSAGE])
Define OLD-MACRO as IMPLEMENTATION. The only difference with
`AC_DEFUN' is that the user will be warned that OLD-MACRO is now
obsolete.
If she then uses `autoupdate', the call to OLD-MACRO will be
replaced by the modern IMPLEMENTATION. The additional MESSAGE is
then printed.
_______________________________________________
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
