[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mingw-msys] Re: MinGW libtool DLL failure

From: Bob Friesenhahn
Subject: Re: [Mingw-msys] Re: MinGW libtool DLL failure
Date: Sat, 19 Oct 2002 10:40:11 -0500 (CDT)

On Fri, 18 Oct 2002, Albert Chin wrote:

> On Tue, Oct 15, 2002 at 10:43:08AM -0500, Bob Friesenhahn wrote:
> > On Tue, 15 Oct 2002, Max Bowsher wrote:
> > >
> > > >> The idea of supporting a --bindir option is tempting, but then
> > > >> 'libtool --mode=install' stops looking like a simple install program,
> > > >> and in fact, the --bindir option would need to be passed for several
> > > >> different phases of libtool operation since it would influence the
> > > >> content of the file.  Since Windows may be the only OS
> > > >> benefiting from this, we could have a case of the tail wagging the
> > > >> dog.
> > >
> > > So we conditionalize all this so it only activates on Windows.
> >
> > There is a fundamental flaw with this logic.  Sorry to dissapoint you,
> > but most open source software using libtool does not originate from
> > the Windows environment. :-)
> >
> > If you rely on a feature which only takes effect under Windows, then
> > packages will neglect to enable or test that feature, resulting in
> > packages which do not build properly (or misbehave) under Windows.
> Doesn't this conflict with the libtool option -no-undefined:
>  - Macro: AC_LIBTOOL_WIN32_DLL
>      This macro should be used if the package has been ported to build
>      clean dlls on win32 platforms.  Usually this means that any

Due to `auto-import' enhancements in the version of binutils used by
Cygwin and MinGW, I believe that using this macro is no longer
necessary.  Packages which have been enhanced (or compromised,
depending on point of view) by being decorated with
dllexport/dllimport annotations may still benefit from use of the

Unix-derived packages which do not use AC_LIBTOOL_WIN32_DLL and do not
incorporate dllexport/dllimport annotations are capable of building
DLLs by incorporating recent libtool.

> It seems that CYGWIN needs -no-undefined but this might be problematic
> on other unices.

It is true that Cygwin/MinGW need -no-undefined in order to build
DLLs.  I have not encountered a problem with specifying -no-undefined
under various unixes.  Indeed, I believe that this issue isn't Windows
specific because IBM's AIX also requires -no-undefined.

In order to ensure that the maximum number of packages will compile
under Windows, the auto* tools should automatically incorporate any
tests/features required for packages to build under Windows without
their authors taking specific action to make this possible.

Bob Friesenhahn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]