On Thursday, April 14, 2005 09:37:13 AM -0700 Russ Allbery <[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
