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