Re: Bug#333141: pam: FTBFS on hurd-i386: Unconditional use of -DWITH_SELINUX
On Tue, Aug 21, 2007 at 04:27:26PM +0200, Michael Banck wrote:
> I tried current svn (svn://svn.debian.org/pkg-pam/trunk/pam/), and the
> following issues arose:
> 1) PATH_MAX usage in modules/pam_cracklib/pam_cracklib.c:
> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libpam/include
> -I../../libpamc/include -g -D_GNU_SOURCE -D_REENTRANT -fPIC -O2 -MT
> pam_cracklib.lo -MD -MP -MF .deps/pam_cracklib.Tpo -c pam_cracklib.c
> -fPIC -DPIC -o .libs/pam_cracklib.o
> pam_cracklib.c:97: error: 'PATH_MAX' undeclared here (not in a function)
> make[4]: *** [pam_cracklib.lo] Error 1
> This is unfortunate as it is in a struct, so fixing this properly is
> maybe not easy. One possiblity is to just conditionalize the
> libcracklib2-dev Build-Depends for hurd-i386 which makes the build
> ignore pam_cracklib and continue successfully, however the build then
> later aborts in binary-arch stage because the pam-cracklib package
> cannot find its files. I am not sure what to best do here, maybe a
> Debian-specific #define PATH_MAX 4096 at the top of pam_cracklib.c is
> easiest.
There's actually no particular need for the static buffer here, in each case
it's just being filled with a strncpy from an existing string with
reasonable scope so a pointer does just as well. Fixed.
> 2) Various libpam source files #include <pthread.h> and use functions
> like pthread_mutex_lock(), but libpam does not link to -lpthread. This
> works on GNU/Linux where libpthread is inside libc, but not on GNU/Hurd
> where it is seperate:
<snip>
> When I add -lpthread to libpam_la_LINK in libpam/Makefile, this works
> fine, but I believe this is a general problem in the build system which
> should get fixed properly in configure.in and Makefile.am etc.
Right, the portable fix is to use -pthread in libpam_la_LDFLAGS. Fixed.
> 3) debian/patches-applied/038_support_hurd has a leftover hunk about
> MAXPATHLEN for modules/pam_rhosts/pam_rhosts_auth.c which yields this
> build error:
<snip>
> as pbuf got otherwise removed from this file, this hunk should get
> removed as well (it seems the other MAXPATHLEN related hunks already got
> removed from 038_support_hurd)
Doh, fixed.
> 4) modules/pam_xauth/pam_xauth.c needs porting:
> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../libpam/include
> -I../../libpamc/include -g -D_GNU_SOURCE -D_REENTRANT -fPIC -O2 -MT
> pam_xauth.lo -MD -MP -MF .deps/pam_xauth.Tpo -c pam_xauth.c -fPIC -DPIC
> -o .libs/pam_xauth.o
> pam_xauth.c:38:23: error: sys/fsuid.h: No such file or directory
> pam_xauth.c: In function 'check_acl':
> pam_xauth.c:203: error: 'PATH_MAX' undeclared (first use in this
> function)
> pam_xauth.c:203: error: (Each undeclared identifier is reported only
> once
> pam_xauth.c:203: error: for each function it appears in.)
> make[4]: *** [pam_xauth.lo] Error 1
> This doesn't look so bad, it can probably be easily fixed in a way
> acceptable to upstream.
Hmm, this is a case where it might be more interesting to preserve the use
of PATH_MAX because the path is assembled via snprintf() and might
legitimately wind up exceeding PATH_MAX on those systems that implement it
if PATH_MAX is otherwise ignored. Well, I've put a patch in svn which
should fix it, we'll see whether it ends up being acceptable to upstream. :)
> 5) After hacking around the above issues I got
> debian/tmp/usr/share/man/man5/namespace.conf.5: No such file or
> directory at /usr/bin/dh_installman line 120, <IN> line 333.
> which is pretty weird considering that this shouldn't be arch-specific
> at all. Maybe some bogus error from restarting dpkg-buildpackage too
> much.
Ok, I've refactored the build rules to use a glob for man5 and manually
exclude those manpages that belong to another package.
Anyone care to give this build another spin?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: