Re: _PATH_LASTLOG

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

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

Thanks for the pointers to doing stuff with PAM. Out of interest, if there
is an interesting answer, is there a good place to write it up?

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 20:06, Rich Felker <dalias@aerifal.cx> wrote:

> On Tue, Dec 03, 2013 at 07:50:21PM +0000, Raphael Cohn wrote:
> > Fair enough. I agree coding absolute paths inside a libc is a bad design.
>
> For what it's worth, there are two issues here:
>
> 1. Hard-coding absolute paths inside libc.
>
> 2. Providing header files with libc that hard-code paths for
>    application usage even though libc does not use these paths for
>    anything and they are purely an application-ecosystem policy
>    matter.
>
> The latter is what I was mildly complaining about glibc doing.
>
> > 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.
>
> :)
>
> For what it's worth, the glibc part of the gnu toolchain is getting
> "less bad". The new maintainership is a lot more friendly and
> responsive to bug reports and willing to go back and fix major cruft,
> but the latter of course requires finding people qualified to
> understand and fix it... :-)
>
> On the other hand, GCC has become a mixed-up mess of C and C++ and
> patchwork of random libraries it outsources its math and optimization
> work to. Sadly this seems to have been kicked off by competition from
> LLVM/clang... libfirm/cparser looks really promising as an alternative
> to both but still has a long ways to go.
>
> > 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?
>
> I recall someone else running into this problem. I think he solved it
> by writing a dummy implementation of these functions that just always
> returns NULL. It might be possible to just #if 0 out the code. You
> might ask on IRC or search the mail archives and see if you can find
> anything about it.
>
> Rich
>

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