Date: Tue, 3 Dec 2013 19:50:21 +0000 From: Raphael Cohn <raphael.cohn@...rmmq.com> To: musl@...ts.openwall.com Subject: Re: _PATH_LASTLOG Fair enough. I agree coding absolute paths inside a libc is a bad design. Frankly, the more I see of the gnu toolchain et al, esp glibc, the less I like. If this was a minor language, I'd say it wasn't fit for real-world use (;-). In practice, it's just showing its age. Thank you for writing musl, and shining a light into some of the horrors. I've hit another roadblock with PAM - innetgr is not defined. It seems there's a configure check for it, which is then not consistently used. Any ideas for a dirty workaround - even if it means some pam modules aren't useful? What would a dummy stub do? PS I'm using musl to compile my own distro set up to get a handle on why the traditionally gnu-based c-compiled world of Linux programs, esp when cross-compiled, is so brittle and bug-prone... Everything I've seen so far, including the GNU toolchain, autoconf, m4, make, libtool (uggh) and its ilk has only confirmed my prejudices - too much ego and high theory, not enough real-world pragmatism. Indeed, most of it seems to be more about copying what was already done without really understanding why it was done the way it was, rather than innovating... Raphael Cohn Chief Architect, stormmq Co-Chair, OASIS MQTT Standard Secretary, OASIS AMQP Standard raphael.cohn@...rmmq.com +44 7590 675 756 UK Office: Hamblethorpe Farm, Crag Lane, Bradley BD20 9DB, North Yorkshire, United Kingdom Telephone: +44 845 3712 567 Registered office: 16 Anchor Street, Chelmsford, Essex, CM2 0JY, United Kingdom StormMQ Limited is Registered in England and Wales under Company Number 07175657 StormMQ.com On 3 December 2013 19:34, Rich Felker <dalias@...ifal.cx> wrote: > 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 > Content of type "text/html" skipped
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.