From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4330 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: _PATH_LASTLOG Date: Tue, 3 Dec 2013 14:34:07 -0500 Message-ID: <20131203193407.GL24286@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1386099258 11825 80.91.229.3 (3 Dec 2013 19:34:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Dec 2013 19:34:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4334-gllmg-musl=m.gmane.org@lists.openwall.com Tue Dec 03 20:34:24 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vnvjh-0003q3-A9 for gllmg-musl@plane.gmane.org; Tue, 03 Dec 2013 20:34:21 +0100 Original-Received: (qmail 22141 invoked by uid 550); 3 Dec 2013 19:34:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 22129 invoked from network); 3 Dec 2013 19:34:20 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4330 Archived-At: 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