Re: _PATH_LASTLOG

[Raphael Cohn <raphael.cohn@stormmq.com>]

[-- Attachment #1: Type: text/plain, Size: 3054 bytes --]

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@stormmq.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@aerifal.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
>

[-- Attachment #2: Type: text/html, Size: 3913 bytes --]