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

[Jeffrey Hutzelman]

On Thursday, April 14, 2005 09:37:13 AM -0700 Russ Allbery 
<rra@stanford.edu> wrote:

> Jeffrey Hutzelman <jhutz@cmu.edu> writes:
>
>> I don't particularly care for libtool.  It imposes a lot of structure
>> trying to solve problems that most people don't actually have, and
>> imposes unnecessary restrictions that make my life annoying.  It plays
>> poorly with objdir builds and DESTDIR installs.
>
> Huh.  My experience is that it plays better with those builds than doing
> things without libtool does (having had a fair bit of experience doing it
> both ways).  libtool has special handling for DESTDIR that gives you some
> hope of actually getting the right shared library paths on platforms like
> HP-UX.

At the expense of making 'make install' just outright fail for packages 
which have multiple interdependent shared libraries, because libtool 
assumes that it is fine to install a library in the DESTDIR and then assume 
it will immediately be available in the real prefix for linking the next 
program against.  We have a standard patch we have to apply to ltmain.sh in 
packages like heimdal that have interdependent shared libraries, so that 
'make install' actually works.  Unfortunately, we can't submit this change 
upstream, because we're pretty sure it will break platforms like HP-UX.

Incidentally, the _right_ answer on HP-UX is to let the linker produce 
whatever it wants, and then change the search path of the resulting binary 
to what it's supposed to be.  One of HP-UX's few redeeming features is that 
it lets you do this.


>> In addition, the problem libtool solves is one we don't actually have.
>> The libraries you're talking about (libafsrpc and libafsauthent) are
>> _already_ available in shared, pthreads-aware versions.
>
> Well, they're not available in a way that people can use to solve the PAM
> problem because they're not built PIC.  Unless I'm missing something?

They're shared libraries.  If the platform requires that shared libraries 
be PIC (and most do) then they will be.



> I'm volunteering to do the work required to get shared libraries that can
> at least be used for PAM purposes, including calling setpag and building
> thread-safe PAM modules.  If a prerequisite for that work is working out
> the library API, that may be more than I can handle.  :/

Heh.  I don't think that should be a prerequisite for making PAM work, just 
that we should do it before we start telling people "this is the One True 
set of libraries; use them".


-- Jeff