[OpenAFS-devel] Re: [OpenAFS] afs_pam2 - A simplier approach to AFS integration during login

[Jim Rees]

I hate libtool.  Like autoconf, it tries to encapsulate all the machine
dependencies in one place, so that individual applications don't have to
worry about what architecture they are running on.  This works fine if
libtool works on the machine you are trying to build for.  If it doesn't
work, it can be very difficult to fix.  Libtool seems to go out of its way
to confound the application developer, even going so far as to hide the real
libraries from view.

I would like to see a libafs.so that contains as much as possible of the
current afs static libraries, and if libtool is the best way to do that I
guess I can look the other way while someone else imports it.

For an example of libtool brokenness that I as an OpenAFS developer would
have a hard time fixing, see the patches in:
/afs/citi.umich.edu/machdep/i386_obsd36/usr/ports/comms/pilot-link/patches

Mozilla would be an example of a large application heavily dependent on
shared libraries that builds fine without libtool.

Then there is the licensing issue.  I assume libtool is GPL.  Would we need
to ship libtool itself, or can it, like autoconf, generate some kind of
non-GPL glue that we could ship with OpenAFS?