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

Russ Allbery rra@stanford.edu
Thu, 14 Apr 2005 08:42:45 -0700


Jim Rees <rees@umich.edu> writes:

> 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.

Yeah, that's one of the reasons why I wanted to ask first before going to
the work of making a patch.  On the other hand, I have to say that libtool
takes care of some deeply obscure stuff that I never would have come up
with in a million years on platforms that I have no access to.  I can try
to write shared library rules by hand, but if I do that, I'll be able to
give you gcc for Solaris and Linux and then everyone else will be on their
own.  libtool would cover more platforms by far out of the box.

It also has the advantage of taking care of the LD_RUN_PATH mess.

On the other hand, shlibafsauthent and shlibafsrpc are already a start on
building shared versions of the libraries I was looking at and have some
compile lines for different platforms.  They don't actually do the right
thing at the moment since they don't build the code PIC, but I know how to
fix that.  I'm not sure what else is missing, though.

> 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.

The approach I was going to take was to libtoolize libafsauthent and
libafsrpc, since those are the new API, the API that should be used by new
external applications, and code that's already somewhat self-contained.

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

Yeah, but Mozilla has way more resources available to develop their build
system than we do, to be honest.

> 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?

# As a special exception to the GNU General Public License, if you
# distribute this file as part of a program that contains a
# configuration script generated by Autoconf, you may include it under
# the same distribution terms that you use for the rest of that program.

It's the same deal as Autoconf.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>