Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1625656 > unrolled thread

[PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens <hauke@hauke-m.de> - 2017-04-18 23:10 +0200
    Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility David Miller <davem@davemloft.net> - 2017-04-20 22:10 +0200
      Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility David Woodhouse <dwmw2@infradead.org> - 2017-04-20 22:20 +0200
        Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility David Miller <davem@davemloft.net> - 2017-04-20 22:40 +0200
          Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility Hauke Mehrtens <hauke@hauke-m.de> - 2017-04-21 15:20 +0200
            Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility David Woodhouse <dwmw2@infradead.org> - 2017-04-21 15:20 +0200
            Re: [musl] Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc  compatibility Rich Felker <dalias@libc.org> - 2017-04-21 20:50 +0200

#1625656 — [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

The code from libc-compat.h depends on some glibc specific defines and 
causes compile problems with the musl libc. These patches remove some 
of the glibc dependencies. With these patches the LEDE (OpenWrt) base 
user space applications can be build with unmodified kernel headers and 
musl libc.

This was compile tested with the user space from LEDE (OpenWrt) with 
musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.

Changes since v1:
 - fix typo in commit message
 - combine two changes


David Heidelberger (1):
  uapi/if_ether.h: prevent redefinition of struct ethhdr

Hauke Mehrtens (2):
  uapi glibc compat: add libc compat code when not build for kernel
  uapi glibc compat: fix build if libc defines IFF_ECHO

 include/uapi/linux/if_ether.h    |  3 +++
 include/uapi/linux/libc-compat.h | 25 +++++++++++++++++++------
 2 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.11.0

[toc] | [next] | [standalone]

#1627778

From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Tue, 18 Apr 2017 23:00:33 +0200

> The code from libc-compat.h depends on some glibc specific defines and 
> causes compile problems with the musl libc. These patches remove some 
> of the glibc dependencies. With these patches the LEDE (OpenWrt) base 
> user space applications can be build with unmodified kernel headers and 
> musl libc.
> 
> This was compile tested with the user space from LEDE (OpenWrt) with 
> musl 1.1.16, glibc 2.25 and uClibc-ng 1.0.22.
> 
> Changes since v1:
>  - fix typo in commit message
>  - combine two changes

I think I have to put the brakes on this patch series, after much
consideration.

It does not scale if we continually add a hodge-podge of different
ifdef tests to the UAPI headers in order to prevent mutliple
definitions.

We will add that IFF_ECHO ifdef for MUSL libc today, and for another
libc we will add another such hack.  And so on and so forth...

Instead, LIBC implementation must adopt the ifdef protections which
have standard names and are being adopted by GLIBC and hopefully
others.

So please instead adjust the musl headers so that they interact
properly with the framework we've designed specifically for this
purpose.

Thank you.

[toc] | [prev] | [next] | [standalone]

#1627784

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2017-04-20 at 16:07 -0400, David Miller wrote:
> 
> I think I have to put the brakes on this patch series, after much
> consideration.
> 
> It does not scale if we continually add a hodge-podge of different
> ifdef tests to the UAPI headers in order to prevent mutliple
> definitions.
> 
> We will add that IFF_ECHO ifdef for MUSL libc today, and for another
> libc we will add another such hack.  And so on and so forth...
> 
> Instead, LIBC implementation must adopt the ifdef protections which
> have standard names and are being adopted by GLIBC and hopefully
> others.

I agree, except I don't think you're going far enough. Those "standard
names" you mention... some of this stuff actually depends on __GLIBC__,
and *that* isn't right either.

I tried to kill that off completely and make the kernel entirely
agnostic, in https://marc.info/?l=linux-api&m=148898383805658&w=2

[toc] | [prev] | [next] | [standalone]

#1627794

From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 20 Apr 2017 21:14:37 +0100

> I agree, except I don't think you're going far enough. Those "standard
> names" you mention... some of this stuff actually depends on __GLIBC__,
> and *that* isn't right either.

Yep, that's something that needs correcting.

[toc] | [prev] | [next] | [standalone]

#1628239

On 04/20/2017 10:36 PM, David Miller wrote:
> From: David Woodhouse <dwmw2@infradead.org>
> Date: Thu, 20 Apr 2017 21:14:37 +0100
> 
>> I agree, except I don't think you're going far enough. Those "standard
>> names" you mention... some of this stuff actually depends on __GLIBC__,
>> and *that* isn't right either.
> 
> Yep, that's something that needs correcting.
> 
Should all libc implementations define __GLIBC__ or could we at least
switch the kernel UAPI to !__KERNEL__ here?

Hauke

[toc] | [prev] | [next] | [standalone]

#1628249

[Multipart message — attachments visible in raw view] — view raw

On Fri, 2017-04-21 at 15:14 +0200, Hauke Mehrtens wrote:
> 
> On 04/20/2017 10:36 PM, David Miller wrote:
> > 
> > From: David Woodhouse <dwmw2@infradead.org>
> > Date: Thu, 20 Apr 2017 21:14:37 +0100
> > 
> > > 
> > > I agree, except I don't think you're going far enough. Those
> > > "standard
> > > names" you mention... some of this stuff actually depends on
> > > __GLIBC__,
> > > and *that* isn't right either.
> > Yep, that's something that needs correcting.
> > 
> Should all libc implementations define __GLIBC__ or could we at least
> switch the kernel UAPI to !__KERNEL__ here?

I'd start with the patch I referenced yesterday...

[toc] | [prev] | [next] | [standalone]

#1628495 — Re: [musl] Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility

On Fri, Apr 21, 2017 at 03:14:21PM +0200, Hauke Mehrtens wrote:
> 
> 
> On 04/20/2017 10:36 PM, David Miller wrote:
> > From: David Woodhouse <dwmw2@infradead.org>
> > Date: Thu, 20 Apr 2017 21:14:37 +0100
> > 
> >> I agree, except I don't think you're going far enough. Those "standard
> >> names" you mention... some of this stuff actually depends on __GLIBC__,
> >> and *that* isn't right either.
> > 
> > Yep, that's something that needs correcting.
> > 
> Should all libc implementations define __GLIBC__

Absolutely not.

Rich

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web