[Top][All Lists]

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

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

From: Vincent Torri
Subject: Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]
Date: Tue, 8 Jun 2010 10:17:51 +0200 (CEST)

On Tue, 8 Jun 2010, Gary V. Vaughan wrote:

[[Adding Libtool List]]

On 8 Jun 2010, at 08:42, Charles Wilson wrote:
Which is why I don't think even the Peter's long-ready MSVC patches, nor
my pile of pending patches, are candidates for this extremely shortened
release cycle.

Regarding these patches, I honestly have paid very little attention to
Windows fixes for libtool because I can't test them,

even if you install mingw cross toolchain on linux ? You can even test Windows CE with cegcc on linux

Vincent Torri

and don't use them:
So I figured someone else was taking care of it.  Since that obviously
isn't the case, and because I'd hate to see them bitrotting indefinitely
in the list archives, we can either commit them on the trunk after 2.2.10,
or else create a topic branch in git to collect them together for testing
and merging back at an appropriate point.

Chuck, Peter, you both have commit rights, correct?  Would you be willing
to round up those pending patches and shepherd them into the tree?

I'm planning to put out a new libtool point release every few months from
now on, as long as something worthwhile has been added to the code since
the previous release.

Note, btw, that the only reason we haven't been deluged with complaints
about that latter, is that cygwin and MinGW both distribute a forked
libtool package that has been patched to deal with these issues.  It is
*routine* on cygwin to ALWAYS reautoconf EVERY package you try to build,
mostly to pull in the working libtool instead of the official libtool
the package shipped with.

Yikes. Well, I'd like to fix that too.  If the fork is well tested
already (as seems to be the case), and we can verify that merging it
back into git won't cause regressions on other platforms, I'd very much
like to fold all of that back into 2.2.12 for sometime in early August.

If one of you would create a topic branch for unmerged Windows patches
and commit the things that belong in upstream, I'll test them on the
platforms I have access to, and merge them back into master if there
are no issues.  Or, if it turns out that they are big and destabilizing,
then I'll make a 2.2.x release branch for 2.2.12, and we can start
thinking about a Windows friendly 2.4.0 towards the end of the year.

Gary V. Vaughan (address@hidden)


reply via email to

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