Re: sys/signal.h, sys/dirent.h + bugzilla.

[Rich Felker <dalias@aerifal.cx>]

On Fri, Aug 24, 2012 at 09:10:47AM -0400, idunham@lavabit.com wrote:
> > On Fri, Aug 24, 2012 at 02:19:55PM +0200, John Spencer wrote:
> >> On 08/24/2012 12:40 PM, Daniel CegieÅ*ka wrote:
> >> >Hi,
> >> >
> >> >e2fsprogs (misc/fsck.c) needs include/sys/signal.h, but musl installs
> >> >signal.h only in include/. symlink in Makefile?
> >> >
> >> >btw. the same situation: sys/dirent.h
> >>
> 
> >> those are not posix, the package you're trying to compile is at fault
> >> here.
> it's util-*linux*, not util-posix - what do you expect? :P
> >
> > Yes. We've already handled _some_ broken things like this by just
> > adding the nonsense alias for the header (as a wrapper rather than a
> > symlink, though; using symlinks is a bad idea because installing them
> > does not work well) but so far this is the only report I've seen of an
> > app needing these two
> 
> I've seen sys/syscall.h previously. Easily fixed.
> I have considered doing a glibc-header-compat package, which provides
> various nonstandard headers (sys/ aliases, sys/queue.h, etc.) out of tree.
> I don't think they belong in tree.

I'm not sure how having a separate package for 5-10 one-line .h files
is beneficial. Sounds like something the X.org folks would have come
up with... especially if you want to package them with a 600k
configure script. :-)

> BTW, util-linux will probably need to check unistd.h for an adequate
> standards-support (_XOPEN_VERSION/_POSIX_VERSION).  Allegedly, they
> support every libc out there, and a number of older ones don't even have
> <syscall.h>.

<sys/syscall.h> is the correct name; <syscall.h> is wrong. Neither is
standard of course, but the former is the historical location and the
latter seems to have been added by glibc at some point for no apparent
reason.

Rich