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. I'm not saying it doesn't suck, just that I've had it suck less than trying to roll one's own build rules. > 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? > Finally, I'm not sure I agree with your assertion that these are the > "new" API's that everything should use. While they begin to move in the > right direction with respect to library makeup, it's not quite right, > and if we're going to spend effort in this area, we should try to do > something that doesn't suck, and that's consistent along both the > static-vs-shared and lwp-vs-pthread axes. Okay, well, on that I'm just repeating what I was told, so I may well be completely wrong. 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. :/ -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
