Date: Thu, 30 Aug 2012 14:56:46 -0700 From: Isaac Dunham <idunham@...abit.com> To: musl@...ts.openwall.com Subject: Re: sys/signal.h, sys/dirent.h + bugzilla. On Fri, 24 Aug 2012 13:43:35 -0400 Rich Felker <dalias@...ifal.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
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.