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 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 >