Date: Tue, 3 Dec 2013 14:34:07 -0500 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: _PATH_LASTLOG On Tue, Dec 03, 2013 at 05:44:04PM +0000, Raphael Cohn wrote: > Hi, > > I'm trying to compile linux-pam 1.1.8 using musl-cross, and I've hit a > compilation error in modules/pam_lastlog/pam_lastlog.c > > Essentially, this code includes the clib utmp.h (based on HAVE_UTMP_H) and > then assumes _PATH_LASTLOG is defined. This is a bug in pam. It should be testing #ifdef _PATH_LASTLOG. _PATH_LASTLOG is not specified to be defined anywhere, much less utmp.h; its presence is a glibc "feature". At present musl has some of these paths that are fairly universally-agreed-upon in paths.h, but it's really bad design for libc to be imposing policy for things that have nothing to do with libc itself through the headers it installs. (In fact, if I'm not mistaken, most distros patch glibc's paths.h to conform to their FS layours...) > utmp.h doesn't define this macro, but does define _PATH_UTMP and > _PATH_WTMP. Should it? (And why are they set to /dev/null/xxx )? These are all very good questions. At present musl does not support storing anything to utmp, and uses /dev/null/xxx as a pathname that will fail to open and fail to unlink (since /dev/null is required by POSIX to exist as a device, i.e. not a directory). (Using /dev/null would be dangerous since some broken programs unlink the utmp file and make a new one.) Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.