Date: Thu, 3 Mar 2016 18:01:24 +0100 From: Szabolcs Nagy <nsz@...t70.net> To: musl@...ts.openwall.com Subject: Re: iproute2 & other software * Kylie McClain <somasissounds@...il.com> [2016-03-03 11:12:09 -0500]: > On Thu, Mar 3, 2016 at 11:00 AM, Rich Felker <dalias@...c.org> wrote: > > On Thu, Mar 03, 2016 at 11:10:06AM +0100, Szabolcs Nagy wrote: > >> * Rich Felker <dalias@...c.org> [2016-03-02 18:30:50 -0500]: > >> > On Wed, Mar 02, 2016 at 09:49:41PM +0100, Szabolcs Nagy wrote: > >> > > musl cannot use the same workarounds because they use ifdef __GLIBC__ > >> > > (which is a major bug for linux uapi headers to depend on): > >> > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/libc-compat.h > >> > > >> > Would it help for us to define the __UAPI_DEF_* macros? If so I'd be > >> > >> no, because they are defined unconditionally in libc-compat.h, > >> however we could define _UAPI_LIBC_COMPAT_H to make the conflicting > >> type definitions disappear. > >> > >> but that is still fragile: any libc header would disable all > >> typedefs, while in glibc the checks are more fine grained. > > > > That sounds viable (we never want _any_ kernel definitions that > > conflict with standard ones) but I don't like the mechanism (poking at > > their multiple-inclusion-guard macro). Likewise I don't like how > > they're peeking at libc's private multiple-inclusion-guard macros. > > > >> we could also submit a linux patch to make the non-__GLIBC__ > >> case more reasonable (e.g. check for existing definition of > >> the macros). > > > > I think that sounds more reasonable. > > > > What would be ideal would be a macro we could define from features.h > > or even stdc-predef.h that says "libc defines all the standard types; > > we don't want kernel headers trying to define them", which the kernel > > headers would honor via: > > > > #ifdef _LIBC_DEFINES_STD_TYPES > > #include <netinet/in.h> > > #else > > /* their own definitions */ > > #endif > > > > but I suspect that would be controversial on the kernel side. > > > > Rich > > I had patches to take care of this stuff in the kernel headers, I've just > been procrastinating sending them into the lkml, if anyone else feels like > handling this. I really don't want to deal with the lkml. > if you submit such patches please cc them to linux-api@...r.kernel.org there is more chance to get meaningful discussion there. (in general you might want to use scripts/get_maintainers.pl from the kernel tree to make sure all interested parties see the patch, unfortunately that does not handle linux-api list correctly, but that's the right place for discussing such changes.) > They were originally adapted from the patches that Sabotage, Void, Alpine, etc. > use for their headers, but they needed some updating for the latest git master. -/* We have included glibc headers... */ -#if defined(__GLIBC__) +/* We're used from userspace, */ +#ifndef __KERNEL__ this change is not ok, they are trying to check whether glibc or kernel headers were included first, not whether user space or kernel space code is being compiled. i think it is better to leave the glibc parts alone, because then we need to coordinate with both the kernel and glibc. btw openwall does not seem to archive binary attachments, but gmail marked your patches as application/octet-stream, may be you can change some setting (or change the file extension) to get them archived.
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.