Sorry if it has been discussed and thrown away before :) There are two aspects of shared libraries functionality - 1. to be able to share one instance of a library between many applications 2. to be able to build executable's functionality at runtime The first one doesn not matter for pam. The second one is very essential. I suppose there are platforms of interest that lack the second (doesn't matter if they implement the first), or that implement it in rather specific ways. Libpam would probably profit in portability and cleaner conceptual design, if it would imploy architecture-independent modules a la Xfree86-4 instead of the platform-specific shared libraries. I have no idea how big job would it be to change the relevant code, but it would bring certain advantages. At least it would be easier for beginners to understand the underlying ideas, as the two things: "a shared library libpam.so" plus "a shared library pam_xyz.so" looks rather confusing, especially given the complicated system-dependent documentation about shared objects... "the libpam library" against "a loadable module xyz" helps a lot, and isolates pam concepts from shared-libraries-that-are-a-complex-and-controversial-subject :) My 2 cents -- Ivan
