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.
>
> 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;
}
in them. So that they are available when PAM they are compiled with this
new libpam version.
Please take a minute to either read my e-mails in depth or go through the
sources yourself before taking a wild guess.
Regards
Javier
signature.asc
Description: Digital signature
