Re: new release?

[Roumen Petrov]

Hi Alex Ameen,

Alex Ameen wrote:

This is a good question. I plan on making a new release this month.

When I first adopted the project I ambitiously thought I'd manage to create a 
new release after about a month; but the truth is when I started doing a deep 
dive into the internals there was a lot of history and complexity for me to 
unpack. Things that are easy to overlook like how change-logs get generated, 
quirks in the testing framework, and tracing down disparate areas to align 
documentation took quite a while to navigate.


Last maintainer heavy broke libtool scrips we "automatic" code formatting 
scrips.
Happy hacking such  brokenness.




The good news is that I think I've got the confidence to push a release soon. One area 
that I was reading up on this weekend was whether the "alpha"/private releases 
of `libtool' might be appropriate, or whether I should just push a release immediately. 
I'll admit I am leaning towards just making a release to avoid the entire alpha process 
for the time being.

I appreciate you reaching out; I definitely want to get a release out before 
March.


More feasible is to apply patches to 2.4.6 branch and to release from this 
really stable and proven to work version.
IN such case next could be 2.4.8.


Next point is name of development branch.
For some reasons projects switch to main branch. Following move libtool could 
create main branch based on 2.4.6.
From main branch could be released 2.6.
It seems to me more users will test release version then beta or release 
candidate.


[SNIP]

Regards,
Roumen Petrov

Re: new release?

[Sam James]

On Sun, 6 Feb 2022 12:21:34 -0600 (CST)
Bob Friesenhahn  wrote:

> On Sun, 6 Feb 2022, Daniel Herring wrote:
> >
> > In my opinion, frequent slow releases are way better than rare fast
> > releases.  
> 
> That may be true for some software, but libtool has a really good
> test suite so if tests pass, there is high confidence of quality for
> the systems it has been executed on.  It is abnoxiously painful to
> build libtool starting from git sources so hardly anyone is testing
> the unreleased code.
> 
> Pushing out a release assures that the mechanics are working and that 
> it is even possible to create a release.
> 
> Users are much more apt to report bugs and patches against software 
> that they can easily use.

Yep!

Especially given that distros are obviously going to be careful with
testing libtool, even more so given they (we!) know development is
resuming after a long haitus, and we're checking which of our patches
are still relevant, etc. It's not like it'll be bumped downstream
without anybody doing due diligence :)

best,
sam



pgpBmoMpg8rkj.pgp
Description: OpenPGP digital signature

Re: new release?

[Sam James]

On Mon, 7 Feb 2022 12:14:29 -0600
Alex Ameen  wrote:

> Thanks for all of the advice y'all.
> 
> I'm going to get this release together as soon as possible and resolve
> issues from there.
> 
> I agree that paralysis set in a bit as a result of me trying to test
> a bit overboard on my own ( lots of VMs ). I appreciate the reality
> check :)

Just let us know if you do need help. It's okay to even just get to
a point where you're happyish, send an email asking for testers from
master, and ask people to send you e.g. test suite results. A fair
amount of projects do this.

Thanks again for taking up the torch and +1 to everything
vapier said in this thread.

Gentoo has a stack of patches we'd like to push forward but my intention
at least is to wait until this next release b/c:
1. it's a burden on you (with too many people sending lots of huge
changes);
2. a fair amount of our changes (and most distros'!) will actually
end up being either similar or the same, at least in the result they
produce, so it's hard to know what to send until stuff all lands in
master. It's therefore easier for everyone for the short-term (just
until this first release is out or so) and we know what we're rebasing
on, etc.

Keep at it!

best,
sam


pgpJ7sczWsYgS.pgp
Description: OpenPGP digital signature

Re: new release?

[Daniel Herring]

No worries.  Glad someone is carrying the project forward.

Next time, consider using the "slow process" as "outsourced QA testing". 
It might be easier and faster.  :)


-- Daniel


On Mon, 7 Feb 2022, Alex Ameen wrote:


Thanks for all of the advice y'all.
I'm going to get this release together as soon as possible and resolve issues 
from there.

I agree that paralysis set in a bit as a result of me trying to test a bit 
overboard on my own ( lots of VMs ). I appreciate the reality check
:) 

On Mon, Feb 7, 2022, 4:54 AM Frederic Berat  wrote:
  On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger  wrote:
  >
  > On 06 Feb 2022 11:56, Daniel Herring wrote:
  > > FWIW, libtool is a particularly difficult code base to release.  Long
  > > history, many users, multi-platform, ...
  > >
  > > I would personally recommend the "slow" process unless you are 
confident
  > > this release will "do no harm".  It was made for a reason, even if it
  > > feels nobody is participating.  Relax, practice the release process,
  > > spread the news and give people time to respond, build a good 
reputation,
  > > have cover in case bugs are found later, ...
  >
  > no software is ever bug free.  being paralyzed by "is it ready yet" and
  > never making a release as a result makes the problem worse.  infrequent
  > releases tend to lead to large accumulation of changes which makes them
  > even more unstable because the interactions are never tested.
  >
  > libtool has a testsuite.  if bugs are found, fix them, add more tests.
  > iterate and move on.
  > -mike

  I'd agree with these statements.

  What happened with autoconf is an extreme case, but is a good example of 
it.
  Distros stuck to 2.69 for years, and when 1.70 finally came out, there
  has been a big amount of breakage.

  Releases are integrated by early distro adopters, who will find
  problems that are not covered by the tests, and forward them here.
  If you don't release your code, this wide coverage isn't here and the
  machinery gets rusty.

  Fred.

Re: new release?

[Alex Ameen]

Thanks for all of the advice y'all.

I'm going to get this release together as soon as possible and resolve
issues from there.

I agree that paralysis set in a bit as a result of me trying to test a bit
overboard on my own ( lots of VMs ). I appreciate the reality check :)

On Mon, Feb 7, 2022, 4:54 AM Frederic Berat  wrote:

> On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger  wrote:
> >
> > On 06 Feb 2022 11:56, Daniel Herring wrote:
> > > FWIW, libtool is a particularly difficult code base to release.  Long
> > > history, many users, multi-platform, ...
> > >
> > > I would personally recommend the "slow" process unless you are
> confident
> > > this release will "do no harm".  It was made for a reason, even if it
> > > feels nobody is participating.  Relax, practice the release process,
> > > spread the news and give people time to respond, build a good
> reputation,
> > > have cover in case bugs are found later, ...
> >
> > no software is ever bug free.  being paralyzed by "is it ready yet" and
> > never making a release as a result makes the problem worse.  infrequent
> > releases tend to lead to large accumulation of changes which makes them
> > even more unstable because the interactions are never tested.
> >
> > libtool has a testsuite.  if bugs are found, fix them, add more tests.
> > iterate and move on.
> > -mike
>
> I'd agree with these statements.
>
> What happened with autoconf is an extreme case, but is a good example of
> it.
> Distros stuck to 2.69 for years, and when 1.70 finally came out, there
> has been a big amount of breakage.
>
> Releases are integrated by early distro adopters, who will find
> problems that are not covered by the tests, and forward them here.
> If you don't release your code, this wide coverage isn't here and the
> machinery gets rusty.
>
> Fred.
>
>
>

Re: new release?

[Frederic Berat]

On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger  wrote:
>
> On 06 Feb 2022 11:56, Daniel Herring wrote:
> > FWIW, libtool is a particularly difficult code base to release.  Long
> > history, many users, multi-platform, ...
> >
> > I would personally recommend the "slow" process unless you are confident
> > this release will "do no harm".  It was made for a reason, even if it
> > feels nobody is participating.  Relax, practice the release process,
> > spread the news and give people time to respond, build a good reputation,
> > have cover in case bugs are found later, ...
>
> no software is ever bug free.  being paralyzed by "is it ready yet" and
> never making a release as a result makes the problem worse.  infrequent
> releases tend to lead to large accumulation of changes which makes them
> even more unstable because the interactions are never tested.
>
> libtool has a testsuite.  if bugs are found, fix them, add more tests.
> iterate and move on.
> -mike

I'd agree with these statements.

What happened with autoconf is an extreme case, but is a good example of it.
Distros stuck to 2.69 for years, and when 1.70 finally came out, there
has been a big amount of breakage.

Releases are integrated by early distro adopters, who will find
problems that are not covered by the tests, and forward them here.
If you don't release your code, this wide coverage isn't here and the
machinery gets rusty.

Fred.

Re: new release?

[Mike Frysinger]

On 06 Feb 2022 11:56, Daniel Herring wrote:
> FWIW, libtool is a particularly difficult code base to release.  Long 
> history, many users, multi-platform, ...
> 
> I would personally recommend the "slow" process unless you are confident 
> this release will "do no harm".  It was made for a reason, even if it 
> feels nobody is participating.  Relax, practice the release process, 
> spread the news and give people time to respond, build a good reputation, 
> have cover in case bugs are found later, ...

no software is ever bug free.  being paralyzed by "is it ready yet" and
never making a release as a result makes the problem worse.  infrequent
releases tend to lead to large accumulation of changes which makes them
even more unstable because the interactions are never tested.

libtool has a testsuite.  if bugs are found, fix them, add more tests.
iterate and move on.
-mike


signature.asc
Description: PGP signature

Re: new release?

[Bob Friesenhahn]

On Sun, 6 Feb 2022, Daniel Herring wrote:


In my opinion, frequent slow releases are way better than rare fast releases.


That may be true for some software, but libtool has a really good test 
suite so if tests pass, there is high confidence of quality for the 
systems it has been executed on.  It is abnoxiously painful to build 
libtool starting from git sources so hardly anyone is testing the 
unreleased code.


Pushing out a release assures that the mechanics are working and that 
it is even possible to create a release.


Users are much more apt to report bugs and patches against software 
that they can easily use.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt

Re: new release?

[Alexei Podtelezhnikov]

On Sun, Feb 6, 2022 at 11:57 AM Daniel Herring  wrote:
> I would personally recommend the "slow" process unless you are confident
> this release will "do no harm".

Hasn't it been slow enough already? Some say the project is finished.

Re: new release?

[Daniel Herring]

FWIW, libtool is a particularly difficult code base to release.  Long 
history, many users, multi-platform, ...


I would personally recommend the "slow" process unless you are confident 
this release will "do no harm".  It was made for a reason, even if it 
feels nobody is participating.  Relax, practice the release process, 
spread the news and give people time to respond, build a good reputation, 
have cover in case bugs are found later, ...


In my opinion, frequent slow releases are way better than rare fast 
releases.


-- Daniel


On Sun, 6 Feb 2022, Richard Purdie wrote:


On Sat, 2022-02-05 at 21:06 -0500, Mike Frysinger wrote:

On 05 Feb 2022 15:15, Alex Ameen wrote:

This is a good question. I plan on making a new release this month.

When I first adopted the project I ambitiously thought I'd manage to
create a new release after about a month; but the truth is when I
started doing a deep dive into the internals there was a lot of history
and complexity for me to unpack. Things that are easy to overlook like
how change-logs get generated, quirks in the testing framework, and
tracing down disparate areas to align documentation took quite a while
to navigate.

The good news is that I think I've got the confidence to push a release
soon. One area that I was reading up on this weekend was whether the
"alpha"/private releases of `libtool' might be appropriate, or whether I
should just push a release immediately. I'll admit I am leaning towards
just making a release to avoid the entire alpha process for the time being.


i wouldn't sweat it too much.  the next release of libtool will be 2.6, and
you can note its state in the announcement/NEWS.  distros will give it a run
to find regressions, and as fixes are merged, just do 2.6.1, 2.6.2, etc...



I'd like to second that. Getting a release out would be great even if it isn't
perfect, then go from there.

I know there are some Yocto Project patches for issues we've collected from
across the embedded ecosystem over the last few years that I rebased and posted
in the hope they could be merged. I'd rather we got to those in due course and
had a release though! :)

Cheers,

Richard

Re: new release?

[Richard Purdie]

On Sat, 2022-02-05 at 21:06 -0500, Mike Frysinger wrote:
> On 05 Feb 2022 15:15, Alex Ameen wrote:
> > This is a good question. I plan on making a new release this month.
> > 
> > When I first adopted the project I ambitiously thought I'd manage to 
> > create a new release after about a month; but the truth is when I 
> > started doing a deep dive into the internals there was a lot of history 
> > and complexity for me to unpack. Things that are easy to overlook like 
> > how change-logs get generated, quirks in the testing framework, and 
> > tracing down disparate areas to align documentation took quite a while 
> > to navigate.
> > 
> > The good news is that I think I've got the confidence to push a release 
> > soon. One area that I was reading up on this weekend was whether the 
> > "alpha"/private releases of `libtool' might be appropriate, or whether I 
> > should just push a release immediately. I'll admit I am leaning towards 
> > just making a release to avoid the entire alpha process for the time being.
> 
> i wouldn't sweat it too much.  the next release of libtool will be 2.6, and
> you can note its state in the announcement/NEWS.  distros will give it a run
> to find regressions, and as fixes are merged, just do 2.6.1, 2.6.2, etc...
> 

I'd like to second that. Getting a release out would be great even if it isn't
perfect, then go from there.

I know there are some Yocto Project patches for issues we've collected from
across the embedded ecosystem over the last few years that I rebased and posted
in the hope they could be merged. I'd rather we got to those in due course and
had a release though! :)

Cheers,

Richard

Re: new release?

[Mike Frysinger]

On 05 Feb 2022 15:15, Alex Ameen wrote:
> This is a good question. I plan on making a new release this month.
> 
> When I first adopted the project I ambitiously thought I'd manage to 
> create a new release after about a month; but the truth is when I 
> started doing a deep dive into the internals there was a lot of history 
> and complexity for me to unpack. Things that are easy to overlook like 
> how change-logs get generated, quirks in the testing framework, and 
> tracing down disparate areas to align documentation took quite a while 
> to navigate.
> 
> The good news is that I think I've got the confidence to push a release 
> soon. One area that I was reading up on this weekend was whether the 
> "alpha"/private releases of `libtool' might be appropriate, or whether I 
> should just push a release immediately. I'll admit I am leaning towards 
> just making a release to avoid the entire alpha process for the time being.

i wouldn't sweat it too much.  the next release of libtool will be 2.6, and
you can note its state in the announcement/NEWS.  distros will give it a run
to find regressions, and as fixes are merged, just do 2.6.1, 2.6.2, etc...
-mike


signature.asc
Description: PGP signature

Re: new release?

[Alex Ameen]

This is a good question. I plan on making a new release this month.

When I first adopted the project I ambitiously thought I'd manage to 
create a new release after about a month; but the truth is when I 
started doing a deep dive into the internals there was a lot of history 
and complexity for me to unpack. Things that are easy to overlook like 
how change-logs get generated, quirks in the testing framework, and 
tracing down disparate areas to align documentation took quite a while 
to navigate.


The good news is that I think I've got the confidence to push a release 
soon. One area that I was reading up on this weekend was whether the 
"alpha"/private releases of `libtool' might be appropriate, or whether I 
should just push a release immediately. I'll admit I am leaning towards 
just making a release to avoid the entire alpha process for the time being.


I appreciate you reaching out; I definitely want to get a release out 
before March.



On 2/2/22 1:21 AM, Werner LEMBERG wrote:

Alex,


can you estimate when you will be able to do a new release?  Just to
tell people that the project is still alive :-)


 Werner

new release?

[Werner LEMBERG]

Alex,


can you estimate when you will be able to do a new release?  Just to
tell people that the project is still alive :-)


Werner

Re: New release?

[Vincent Lefevre]

On 2020-05-24 14:24:12 +0200, Marc Nieper-Wißkirchen wrote:
> Please excuse if this has been asked recently and I have missed it.
> 
> I'd like to ask when or whether we can expect a new libtool release? Many
> improvements have happened since the last release. For example, many builds
> are plagued with the warning "ar: `u' modifier ignored since `D' is the
> default (see `U')", which seems to be fixed in [1], but this patch is not
> in the latest release (although 5 years old).

I hope that some bugs will be fixed first, such as

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20622

with a patch:

  https://lists.gnu.org/archive/html/libtool-patches/2015-05/msg0.html

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

New release?

[Marc Nieper-Wißkirchen]

Please excuse if this has been asked recently and I have missed it.

I'd like to ask when or whether we can expect a new libtool release? Many
improvements have happened since the last release. For example, many builds
are plagued with the warning "ar: `u' modifier ignored since `D' is the
default (see `U')", which seems to be fixed in [1], but this patch is not
in the latest release (although 5 years old).

Thanks,

Marc

--

[1]
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=418129bc63afc312701e84cb8afa5ca413df1ab5

Re: Cut a new release?

[Bob Friesenhahn]

On Thu, 27 Sep 2018, Robert Boehne wrote:


I would be more than happy to cut a release, if only I could remember how.
I think the last version I released was 1.5.x - I'll look around but if
anyone on the list remembers where the instructions are - please help me
out ;)


I think that there are useful instructions in the libtool source 
repository.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Cut a new release?

[Mike Gran]

On Thu, Sep 27, 2018 at 08:56:20AM -0700, Robert Boehne wrote:
> I would be more than happy to cut a release, if only I could remember how.
> I think the last version I released was 1.5.x - I'll look around but if
> anyone on the list remembers where the instructions are - please help me
> out ;)

You can check out the process at

https://www.gnu.org/prep/maintain/maintain.html#Distributions

I have never contributed to libtool, but, I've made official GNU
releases for other projects. So, feel free to hit me up if you have
any questions at all.

Regards,

Mike Gran


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Cut a new release?

[Robert Boehne]

I would be more than happy to cut a release, if only I could remember how.
I think the last version I released was 1.5.x - I'll look around but if
anyone on the list remembers where the instructions are - please help me
out ;)

Thanks,

Rob Boehne

On Fri, Sep 21, 2018 at 5:50 AM Samuel Tardieu  wrote:

> Hi.
>
> Since libtool latest release 3 years ago, some important problems have
> been patched. In particular, "-fuse-ld=…" is now propagated to the
> driver when linking.
>
> For example, it is not possible to build LLVM modules using libtool on
> Ubuntu LTS using only released packages. "llvm-config --cxxflags"
> outputs "… -fuse-ld=gold -Wl,--no-keep-files-mapped …",  and only the
> linker option "--no-keep-files-mapped" is passed to the driver
> (g++/clang++) while "-fuse-gold=ld" is dropped, causing GNU ld to halt
> with an error because "--no-keep-files-mapped" is a gold-only option.
>
> This is a known problem which has been fixed in libtool repository in
> Feb. 2016 (f9970d99293faf908fdc153a653fa5781095fb7a), but no libtool
> release seems to have taken place since then.
>
> Would it be possible to cut a formal release?
>
>   Sam
>
>
>
> ___
> https://lists.gnu.org/mailman/listinfo/libtool
>
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Cut a new release?

[Bob Friesenhahn]

On Fri, 21 Sep 2018, Samuel Tardieu wrote:

Libtool is in need of additional volunteers to serve as maintainers to
help catch up on the backlog of patches/issues and prepare another
release.


My question was solely about tagging and cutting a new release from the
current state of the repository so that patches contributed by volunteers
and accepted in the repository already get a more widespread distribution.


Volunteers with the necessary energy, time, and resources are 
necessary in order to perform this function.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Cut a new release?

[Samuel Tardieu]

Le ven. 21 sept. 2018 à 15:09, Bob Friesenhahn 
a écrit :

> On Fri, 21 Sep 2018, Samuel Tardieu wrote:
> >
> > Would it be possible to cut a formal release?
>
> Libtool is in need of additional volunteers to serve as maintainers to
> help catch up on the backlog of patches/issues and prepare another
> release.
>

My question was solely about tagging and cutting a new release from the
current state of the repository so that patches contributed by volunteers
and accepted in the repository already get a more widespread distribution.
I understand how getting through QA for doing a new release can be time
consuming (unless the current commits already went through an exhaustive
enough CI run). Note that some distributions such as ArchLinux have been
using the current git HEAD as their sanctioned libtool package. This should
increase the confidence that the current git HEAD behaves better than the
latest release.

  Sam
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Cut a new release?

[Bob Friesenhahn]

On Fri, 21 Sep 2018, Samuel Tardieu wrote:


Would it be possible to cut a formal release?


Libtool is in need of additional volunteers to serve as maintainers to 
help catch up on the backlog of patches/issues and prepare another 
release.


Are you able to volunteer to be a libtool maintainer?

Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/

___
https://lists.gnu.org/mailman/listinfo/libtool

Cut a new release?

[Samuel Tardieu]

Hi.

Since libtool latest release 3 years ago, some important problems have
been patched. In particular, "-fuse-ld=…" is now propagated to the
driver when linking.

For example, it is not possible to build LLVM modules using libtool on
Ubuntu LTS using only released packages. "llvm-config --cxxflags"
outputs "… -fuse-ld=gold -Wl,--no-keep-files-mapped …",  and only the
linker option "--no-keep-files-mapped" is passed to the driver
(g++/clang++) while "-fuse-gold=ld" is dropped, causing GNU ld to halt
with an error because "--no-keep-files-mapped" is a gold-only option.

This is a known problem which has been fixed in libtool repository in
Feb. 2016 (f9970d99293faf908fdc153a653fa5781095fb7a), but no libtool
release seems to have taken place since then.

Would it be possible to cut a formal release?

  Sam



___
https://lists.gnu.org/mailman/listinfo/libtool

Re: New release with OSX Yosemite fix?

[Ozkan Sezer]

On 10/23/14, Gary V. Vaughan  wrote:
>> On 23 Oct 2014, at 15:06, Volker Braun  wrote:
>>
>> Is there any chance for cutting a new release with the OSX Yosemite
>> version parsing fix? This is going to affect a lot of users, and right
>> now there isn't even a released version of libtools to run reconfigure
>> with.
>>
>> http://lists.gnu.org/archive/html/libtool-patches/2014-09/msg2.html
>
>
> Ugh. I'm surprised that one hasn't bitten me already!
>
> The master branch still has known bugs that I don't want to release, so the
> best bet is to make a patch release from the last stable release. The
> process is fiddly and takes several hours to complete though, so I'll leave
> it for a few days to give people a chance to point me at any other critical
> patches that should be rolled in too...
>
> Cheers,
> --
> Gary V. Vaughan (gary AT gnu DOT org)

I'd like to see this particular one in such an interim release:
http://git.savannah.gnu.org/gitweb/?p=libtool.git;a=commit;h=0ebb734910bf56186dd0c0e84b1c8be507bad336
to fix http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15321

--
O.S.

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: New release with OSX Yosemite fix?

[Gary V. Vaughan]

> On 23 Oct 2014, at 15:06, Volker Braun  wrote:
> 
> Is there any chance for cutting a new release with the OSX Yosemite
> version parsing fix? This is going to affect a lot of users, and right
> now there isn't even a released version of libtools to run reconfigure
> with.
> 
> http://lists.gnu.org/archive/html/libtool-patches/2014-09/msg2.html


Ugh. I'm surprised that one hasn't bitten me already!

The master branch still has known bugs that I don't want to release, so the 
best bet is to make a patch release from the last stable release. The process 
is fiddly and takes several hours to complete though, so I'll leave it for a 
few days to give people a chance to point me at any other critical patches that 
should be rolled in too...

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)___
https://lists.gnu.org/mailman/listinfo/libtool

New release with OSX Yosemite fix?

[Volker Braun]

Is there any chance for cutting a new release with the OSX Yosemite
version parsing fix? This is going to affect a lot of users, and right
now there isn't even a released version of libtools to run reconfigure
with.

http://lists.gnu.org/archive/html/libtool-patches/2014-09/msg2.html

___
https://lists.gnu.org/mailman/listinfo/libtool