Date: Thu, 3 Mar 2016 14:05:32 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: iproute2 & other software On Thu, Mar 03, 2016 at 06:01:24PM +0100, Szabolcs Nagy wrote: > * 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. Yes, I'd like to second that I don't think these patches should be submitted in their current form. They may be suitable for making the headers work right on musl-based dists for now, but the changes to preprocessor logic are not actually correct, and my guess is that proposing something that we can't argue is correct (or at least is best-possible) is going to hurt our chances of getting upstream acceptance. Rich
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.