[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACCP0Gqt0C9HDaNKSCMryCvTMTBZVj+pU9VseoXh5PskPSOf=Q@mail.gmail.com>
Date: Tue, 3 Dec 2013 20:18:28 +0000
From: Raphael Cohn <raphael.cohn@...rmmq.com>
To: musl@...ts.openwall.com
Subject: Re: _PATH_LASTLOG
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@...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 20:06, Rich Felker <dalias@...ifal.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
>
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.
