On Sat, Apr 09, 2005 at 12:34:23AM +0200, Javier Fernández-Sanguino Peña wrote: > On Fri, Apr 08, 2005 at 12:20:10PM -0700, Steve Langasek wrote:
> > "undefined reference" means that libpam.so does not contain symbols for
> > these functions. That's a rather critical problem, considering these are
> > core PAM functions.
> If you took a little bit of time to dig into the source before making
> statements you would see this:
> libpam/include/security/_pam_types.h:
> extern int pam_set_item(pam_handle_t *pamh, int item_type, const void
> *item);
> extern int pam_get_item(const pam_handle_t *pamh, int item_type,
> const void **item);
> These new functions are _external_ to the PAM library itself but
> applications need to build them in.
Um, no, they are not. I don't need to "dig into the source" to know you're
wrong. Check the PAM spec, the API documentation in the pam-doc package, or
the symbol table of any Debian version of libpam.so.0 -- if these symbols
are missing, your build is very badly broken.
> > You also say that applications fail with
> > > ../../libpam/libpam.so: undefined reference to `pam_get_item'
> > > ../../libpam/libpam.so: undefined reference to `pam_set_item'
> > ... which means that the PAM library itself is looking for these functions
> > and can't find them. Upstream bug or not, this .so is totally screwed;
> > this isn't something you can patch around by choosing not to build stuff.
> No, again, you are not reading properly what I said. I said that
> building and _linking_ upstream applications failed with that bug because
> neither the examples (which we don't ship) neiter pam_tally (an application
> PAM installs in /usr/sbin/ but which is neither documented not used) don't
> define pam_get_item or pam_set_item, which any application linking to PAM
> should do. So, yes, this is a bug in the upstream sources and, yes, this
> can potentially mean that other applications that link to PAM sources might
> need to get updated but is _not_ totally screwed.
> I could actually get those to compile just by patching the source and
> adding:
> int pam_set_item(pam_handle_t *blah int blah, void *blah) {
> return 0;
> }
Of course you could get it to compile that way, but that's broken beyond
belief. pam_set_item() is an interface for setting data associated with the
pam_handle_t handle, and *must* be provided by the library.
--
Steve Langasek
postmodern programmer
signature.asc
Description: Digital signature
