[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Thu, 3 Mar 2016 11:12:09 -0500
From: Kylie McClain <somasissounds@...il.com>
To: musl@...ts.openwall.com
Subject: Re: iproute2 & other software
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:
>> > > * Loganaden Velvindron <loganaden@...il.com> [2016-03-02 19:19:13 +0000]:
>> > > > "
>> > > > Sorry, I have to reject this.
>> > > > All include files in include/linux come from headers automatically
>> > > > generated from upstream
>> > > > Linux source. This is the only way to ensure long term ABI/API consistency
>> > > > with kernel.
>> > > >
>> > > > Either fix musl or submit patches to upstream kernel and get them merged.
>> > > > "
>> > > >
>> > > > Can we look into providing somekind of compatibility layer for header files
>> > > > so that it's easier to get upstream projects like iproute2 to support musl ?
>> > > >
>> > >
>> > > in theory the correct solution is to fix the kernel headers
>> > > so they don't collide with posix types in libc headers.
>> > >
>> > > in practice old kernel headers should work too and it's unlikely
>> > > that a complete uapi fix would be accepted into linux any time
>> > > soon so applications should avoid including both libc and kernel
>> > > headers into the same tu.
>> > >
>> > > unfortunately glibc added workarounds into libc and uapi headers
>> > > that make it seem as if mixing linux and libc headers work, so
>> > > now application programmers don't have the incentive to fix this.
>> > >
>> > > 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.
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.
Download attachment "0001-libc-compat.h-set-definitions-only-if-kernel-is-undefined.patch" of type "application/octet-stream" (1897 bytes)
Download attachment "0002-kernel.h-only-include-sysinfo.h-on-glibc.patch" of type "application/octet-stream" (1202 bytes)
Download attachment "0003-fix-struct-redefinition-errors-when-using-netinet-in.h.patch" of type "application/octet-stream" (3952 bytes)
Download attachment "0004-fix-struct-redefinition-errors-when-using-netinet-tcp.h.patch" of type "application/octet-stream" (1704 bytes)
Download attachment "0005-libc-compat.h-set-definitions-only-if-kernel-is-undefined.patch" of type "application/octet-stream" (1897 bytes)
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.
