On Wed, 26 Jan 2005, Greg A. Woods wrote:

> > Speaking for yourself.  Those of us working in diverse heterogeneous
> > environments have no real alternative except static linking
>
> That's not true at all.
>
> It really is quite trivial to get the linker/loader options right such
> that a basic Makefile can work portably across all your diverse
> heterogeneous environments.  Lots of us have done exactly this even long
> before Automake came along

And spent time and resources maintaining these options as OS's and
toolchains evolved.  If you spent any reasonable amount of time doing
heterogeneous platform work for a living, you should already know why that
is a problem.

> However now with GNU Automake the features you seek are far more
> elegantly implemented by automake than by that horrid mess of, well,
> crap, that we call "libtool".

These address different concerns.

Automake is a Makefile abstraction tool that is *also* a policy arbiter.
Libtool is a compiler abstraction tool, and no more.

> The only semi-legitimate problem that libtool still solves somewhat
  [...is...]
> the creation of the wrapper scripts

No, it manages the compile and link logic more readily than the typical
developer would have time and resources to do alone.  ([* from top] Even
worse when the project is open source and likely exposed to more platforms
not available at all to the developer.)

Have you tried working with all of AIX, Darwin, and Cygwin on one project?
Do you have any clue why OpenSSL is such a pain in the ass to keep its
shared library support working?  Or why ASF now uses libtool's configuration
data as part of apxs in Apache 2?

More is required on some platforms to get shlibs to work correctly than
simply twiddling compiler/linker options here and there.  Go deal with a
real heterogeneous environment or a *widely* portable project so you can get
your bearings straightened out, and stop making unfounded claims.

> > It's better than zero awareness, which is the point you're pushing.
>
> But libtool doesn't really raise any true awareness of ABI compatabiilty
> issues -- it simply creates a fog about versioning of shared libraries.

It's quite obvious by this statement that you've never actually tried
integrating libtool into a project, and reading its docs.  The way libtool
does versioning, and recommended criteria to the developer about how to
approach it, are in the damned documentation, so go read it and quit beating
the same broken drum; you're embarassing yourself.

Libtool is not beautiful.  It could be much better.  But it does abstract
the shared library logic enough to reduce maintenance load considerably, and
it's the only tool currently robust enough to do that job on a wide variety
of platforms.  To wit:

> I.e. I'm advocating that we find or create real tools that really do
> help manage ABI compatability and that we promote instead of giving
> false impressions about things like libtool.

You're free to work on such a tool and introduce it as the next great
solution to the problem.  Ranting about libtool's perceived shortcomings
doesn't improve the situation.

The rest of us have work to do, and we need tools that work *today*.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>