libtool update to 2.2.6a

[nox@…]

Changes:

• libtool-devel nuked.
• libtool updated to 2.2.6a.
• Enabled parallel build.
• Fixed livecheck

[blb@…]

This isn't the type of major version change that will break other things, instead requiring a libtool2 (or something to that effect) is it?

[nox@…]

​http://www.gnu.org/software/libtool/news.html

Despite a new and improved M4 interface to Libtool from Autoconf, every effort has been made to retain backwards compatibility with the 1.5.x interfaces. Autoupdate (which ships with Autoconf) will help you upgrade your configure.ac to the new interface when you are ready to migrate.

So even if it does break a port, it will be easy to fix the configure.ac script.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #14894.

[boeyms@…]

Replying to nox@…:

​http://www.gnu.org/software/libtool/news.html

Despite a new and improved M4 interface to Libtool from Autoconf, every effort has been made to retain backwards compatibility with the 1.5.x interfaces. Autoupdate (which ships with Autoconf) will help you upgrade your configure.ac to the new interface when you are ready to migrate.

So even if it does break a port, it will be easy to fix the configure.ac script.

That's fine for those releasing libtool-based software, but it sounds to me like we would have to run autoupdate and then autoconf on every libtool-based port that libtool-2.x breaks, which would add new build time dependencies (which hopefully can be removed later, but that depends on the upstream developers). That also assumes that it would work every time -- if not, we'd have to write patches to fix it as well.

I can tell you that libtool-2.2 broke building libxslt for me, while staying with libtool-1.5.6 worked fine, but that was almost 6 months ago now, I didn't know about autoupdate then, and that was the only port that I tested, so I can't give any indication of how many of our ports would break, or how easy fixing by using autoupdate would be.

Personally, I've been thinking of having a "libtool1" for use with ports that break, and for "libtool" to keep tracking the latest stable version; that way, all we'd have to do to fix broken ports would be to change the dependency from libtool to libtool1. That assumes, however, that libtool-1.x and libtool-2.x can be installed together, and I can't remember whether or not they can. (In addition, I've been wondering whether or not we should create "libtool2" anyway for ports that need it now, with a view to making life easier if and when libtool goes to 3.x.)

What does everyone else think?

[jmroot (Joshua Root)]

I've created libtool1 (r42926, r42928, r42929). Getting ports to use it should just be a matter of switching the dep and setting LIBTOOLIZE=${prefix}/bin/glibtoolize1. So I think we can pull the trigger on the update now, and use autoupdate or switch incompatible ports to libtool1 as needed.

I also updated libtool-devel to 2.3a in r42925, so I don't think it needs nuking.

[jmroot (Joshua Root)]

Any objection to me committing the libtool 2.2.6a update?

[blb@…]

At least the guile ports will probably need to updated to avoid it based on ​guile-devel email.

[dbevans (David B. Evans)]

I'm not sure if this is a show stopper or not, but my understanding is that the gnome 2.24 release code can only use libtool up to 1.5 with code being developed in trunk for next major release that will support 2.

[jmroot (Joshua Root)]

I think most things should only have problems if glibtoolize is run. Guile and libxslt seem to build fine with the new libtool installed, BTW.

[jmroot (Joshua Root)]

Updated libtool in r44411. We can deal individually with ports that break.

[(none)]

Milestone Port Updates deleted