[Top][All Lists]

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

Re: [Mingw-users] Building DLLs using MinGW & libtool

From: Earnie Boyd
Subject: Re: [Mingw-users] Building DLLs using MinGW & libtool
Date: Wed, 12 Jun 2002 11:33:58 -0400

Bob Friesenhahn wrote:
> On Wed, 12 Jun 2002, Earnie Boyd wrote:
> > > > All autoconfiguration tools must have the same prefix, that's why I
> > > > provided the msysDTK.  I have the configured all of the tools to
> > > > --prefix=/usr.
> > >
> > > I am not using any MinGW-specific auto* tools.  I am using the latest
> > > releases of GNU Autoconf, Automake, and current CVS libtool.
> > >
> >
> > How, are you using the current CVS libtool????  How did you build it?
> > How did you configure it?  Did you build autoconf and automake or are
> > you using the ones provided in the msysDTK?  Which has version 1.4.2 of
> > libtool.
> I simply did a CVS checkout from the respository
> ":pserver:address@hidden:/cvsroot/libtool:" as I have
> been doing for several years now (since libtool came into being).
> After CVS libtool is built and installed in the development
> environment, I libtoolize the package so that libtool is included with
> the package.  This eliminates any need for libtool to be included in
> the user's development environment.  My auto/libtool work is done
> using a Sun Solaris system, or a matching Cygwin development
> environment depending on which environment I happen to be using at the
> time.

Ok, so these tools are not the MSYS set.  And you were discussing the
end resulting package being configured within the MSYS/MinGW
environment.  Glad we have that straight.  Either apply the
patch I sent or unset the CONFIG_SITE environment variable if you don't
want the values.

> Libtool 1.4.2 is too broken to meet the needs of our package on
> certain other OS targets.
> > To build the CVS version of libtool I had to modify /etc/
> Yikes!  I have never seen this sort of internals stuff in a
> file.  It seems to presume a particular version/release of
> libtool since the names/meanings of these libtool internal variables
> are subject to change.
> Isn't the proper approach to merge any MinGW/MSYS related settings
> into the offical GNU libtool version so that all libtool-based
> packages benefit?

Only for the developer using the set of tools.  The generated set for
the typical end user of the package would most likely not even have
autoconf/automake/libtool installed.  The supplied served
the purpose of supplying values that were incorrectly guessed regardless
of the version of libtool the package used.  I do understand that I may
need to update that set of values or that the supplied set may have the
incorrect values in some cases.  However, those packages that are setup
to create a dll and using older libtool versions will correctly do so
with the supplied.  The CVS version needs the patch I gave

If you care about the history that caused the decision to supply the see the mingw-msys archives.


reply via email to

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