oath-toolkit-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OATH-Toolkit-help] Underlinking issue with PAM module etc.


From: Simon Josefsson
Subject: Re: [OATH-Toolkit-help] Underlinking issue with PAM module etc.
Date: Sat, 30 Apr 2011 17:56:23 +0200
User-agent: Gnus/5.110016 (No Gnus v0.16) Emacs/23.2 (gnu/linux)

Mitya <address@hidden> writes:

> Hello,
>
> I am now working on Mandriva/Mageia packages for OATH Toolkit, and I've
> faced some minor, but nevertheless important, issues.

Hello and welcome!  Thanks for your interest.

> First, the pam_oath.so module suffers from the so-called
> "underlinking" [1] issue, as soon as it is not explicitly linked with
> libpam.so. While this is generally allowed for modules (libpam.so will
> be implicitly provided by every application that uses PAM), the
> "bon-ton" for PAM modules is to be linked to libpam. Please consider
> checking for libpam with AC_CHECK_LIB(pam, main) in
> pam_oath/configure.ac, or adding pam_oath_so_LIBADD="-lpam" to
> pam_oath/Makefile.am.

Oops.  Should be fixed in master now.

> Second, it is generally not recommended to override libdir variable in
> Makefile.am, but instead introduce your own class like that:
>
> pammoddir = $(PAMDIR)
> pammod_LTLIBRARIES = pam_oath.la

Fixed too.

> Next, PAM does not use libltdl to load its modules, so pam_oath.la is
> completely useless. I do remove it in the RPM spec file after build, but
> this can also be done with makefile.

Do you have a simple recipe for how to do it?

> Finally, autoreconf does not work on release tarball contents, since
> build-aux/git-version-gen is absent. In some cases distro maintainers
> have to autoreconf packages, since some important changes are being
> applied to autoconf/automake files. And most important, it breaks build
> after libtoolize (which is forced by many modern distros), since forced
> libtoolize triggers aclocal.

Fixed too.

> And, thanks a lot for your efforts! OATH Toolkit seems to be a good
> alternative to Tri-D otpd with its complexity unclear status. I wish the
> project and the author good luck.

Thank you!

/Simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]