Re: Shared libraries

[William Ahern <william@...>]

On Wed, May 14, 2014 at 01:23:27PM +0700, Gary V. Vaughan wrote:
> 
> > On 14 May 2014, at 12:35, William Ahern <william@25thandClement.com> wrote:
> > 
> > I'll tell you what's wrong with libtool: versioning. There are a gazillion
> > GNU versions,
> 
> Not true.
> 
> There is 2.4.2, the core stable release since Oct 2011. I make releases
> every 3-4 years in general.

Obviously there aren't a gazillion. But the last time I used libtool was in
about 2007. 6 years later I found out that my packages would no longer build
on newer versions because I wasn't using --tag=CC. The allowable interface
had changed, for better or worse. And that's just one example I found
quickly grepping through my repository history.

Backwards incompatible changes, coupled with the fact that OS X and OpenBSD
have their own native versions, and also that OS X's glibtool (when it still
shipped glibtool with X Code) was incompatible with modern versions (see
above), soured me on libtool.

> > and the most recent versions aren't intended to be used
> > outside of a full-blown autotools build environment.
> 
> Absolutely not true.
> 
> I explicitly state that Libtool can be used without the other autotools in
> the manual. It is one of the goals of the project to support that usage
> model.

"Libtool is fully integrated with Automake (see Introduction), starting with
Automake version 1.2."

"If you want to use libtool in a regular Makefile (or Makefile.in), you are
on your own."

(http://www.gnu.org/software/libtool/manual/html_node/Makefile-rules.html)

Perhaps I've misinterpreted that statement.

> You don't even need Autotools to install Libtool, nor to use the installed
> version. If you want to build a custom in tree Libtool script for your
> package at build time, then you'll need Autotools of course, but the only
> reason people still do that is momentum from the 10-15 year old Libtool
> releases where you couldn't rely on an installed system Libtool.

Many of my projects, which can be quite complex (e.g. supporting non-POSIX
interfaces on Linux, OS X, Solaris, and *BSDs) have zero dependencies. And I
work hard at that. I would love to use libtool _if_ I could easily include
it in my project. But that's not practical, which means I'd have to create
an external dependency on libtool, which just doesn't come on any systems
natively except Linux (at least the GNU version of libtool, that is.)

> > (You can make it work,
> > of course, but the authors have explicitly said they aren't interested in
> > supporting independent usage.)
> 
> Not true. I've never said that.
> 
> If you are having trouble, I'll be happy to help you use it correctly. Or
> if you've found a bug, please report it on bug-libtool@gnu.org, and I'll
> endeavor to fix it.

See above quote. Again, perhaps I've misinterpreted it, but I don't believe
it was a gross mischaracterization.

> > Plus OS X and OpenBSD have their own
> > proprietary versions which mimic different, ancient libtool versions.
> 
> I don't use BSD so can't comment on what they do.
> 
> OSX had an entirely unrelated program called libtool, so you have to
> either install glibtool with mac ports or Homebrew, or use the in-tree
> Libtool that most packages continue to distribute. In any case, I have
> downloaded and installed Libtool 2.4.2 from ftp.gnu.org on all my macs for
> several years without any special changes or local patches required. In
> fact my main dev machine for the last several releases is a Mac.

And how easy is it to ship an in-tree versions _without_ also using
automake?

> > So the invocations are different across platforms unless you include a
> > copy,
> 
> That is the thinking that is keeping other packages in the wrong mindset.
> And I don't believe it has been true for many many years.

I thought I was fairly young, but maybe not.

> It's perfectly valid (and in fact preferred) to just make your Libtool
> using package depend on an installed Libtool. Just like if you have a
> package that needs GTK+, you expect your users to arrange for libgtk to be
> installed first! No need to ship the entire sources for GTK+ and its
> dependencies in every GTK+ using package.

In the world of Linux, people don't mind having a large number of
dependencies. But in portable projects, dependencies of any sort easily turn
into the stuff of nightmares. And the whole _point_ of libtool (I thought)
was to ease portability.

Heck, I can't even _install_ packages on my Solaris VM anymore because my
public key expired, and figuring out how to renew it through Oracle's
byzantine web site is too troublesome at the moment. That means any
dependencies I need have to be done manually.

And I reguarly test my projects on at least 8 different platforms--3 Linux
(Ubuntu 12, Ubuntu 14, Fedora), 2 FreeBSD (9 & 10), NetBSD, OpenBSD, OS X,
Solaris. In the grand scheme making sure libtool exists isn't _that_ big of
a deal, but it's a deal nonetheless. Especially considering that I can
easily build shared libraries on three different compilers (GCC, clang,
SunPro) on any of those platforms without bothering wth libtool.

If I could just include a simple copy of libtool in my projects, I would do
it in a heartbeat. But it's not that simple.

> > but
> > there's no independently maintained libtool script anymore;
> 
> Why do you think that? I've been maintaining it for more than 20 years,
> and quickly made releases that work independently of Autotools. It is
> stable enough that bug fix releases only come along every few years these
> days, and 2.4.2 continues to work very well stand alone as far as I can
> tell on the 25 or so architectures I test on.

I'll admit this conclusion doesn't follow from the above evidence. I don't
have time to track down where I formed this erroneous belief, but I
apologize.

<snip>