Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 30 Aug 2012 14:56:46 -0700
From: Isaac Dunham <>
Subject: Re: sys/signal.h, sys/dirent.h + bugzilla.

On Fri, 24 Aug 2012 13:43:35 -0400
Rich Felker <> 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 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

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.