[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 library.la 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
macro.
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
======================================
Bob Friesenhahn
address@hidden
http://www.simplesystems.org/users/bfriesen
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, (continued)
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, Bob Friesenhahn, 2002/10/15
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, Max Bowsher, 2002/10/15
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, Earnie Boyd, 2002/10/15
- Re: MinGW libtool DLL failure, Soren A, 2002/10/21
- Re: MinGW libtool DLL failure, Bob Friesenhahn, 2002/10/21
- Re: MinGW libtool DLL failure, Russ Allbery, 2002/10/21
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, Albert Chin, 2002/10/19
- Re: [Mingw-msys] Re: MinGW libtool DLL failure,
Bob Friesenhahn <=
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, Guido Draheim, 2002/10/15
- Re: [Mingw-msys] Re: MinGW libtool DLL failure, Max Bowsher, 2002/10/15
Re: MinGW libtool DLL failure, Bob Friesenhahn, 2002/10/12