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

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

[Daniel Cegiełka]

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

Maybe we should start a bugzilla for musl?
http://www.bugzilla.org/

Daniel

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

[John Spencer]

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.

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

[Rich Felker]

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.

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, and it might be nicer to just get the app
fixed...

Rich

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

[idunham]

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

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

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

[Gregor Richards]

On 08/24/12 09:10, 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.
>
> 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>.
>
>
>

Ideally, these headers should contain

#ifndef _GNU_SOURCE
#error This is a nonstandard header.
#endif

Perhaps with _BSD_SOURCE too if the BSDs have similar wonko headers.

With valediction,
  - Gregor Richards

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

[Rich Felker]

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

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

[Isaac Dunham]

On Fri, 24 Aug 2012 13:43:35 -0400
Rich Felker <dalias@aerifal.cx> wrote:
> > 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. :-)

sys/queue.h is decidedly larger than that (more like 600 lines), and
there are a few other large headers containing mainly/only macros.
These are things I've seen a need for in several packages.
I'm thinking that _if_ I ship several macro headers purely for
compatibility, I might as well also have some aliases that make
building software easier.

Re configure scripts: in case you forgot, I've said a few time that I'd
rather edit config.mak. This could be handled quite easily in a few
lines of shell, with test.

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

Compatability with DEC libc (DEC only had <syscall.h>). In other words,
<sys/syscall.h> is historical for Linux, but <syscall.h> has history on
other platforms.

Isaac Dunham