[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170420.160739.1263793303398330801.davem@davemloft.net>
Date: Thu, 20 Apr 2017 16:07:39 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: hauke@...ke-m.de
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
jarod@...hat.com, jogo@...nwrt.org, david.heidelberger@...t.cz,
maillist-linux@...fooze.de, mikko.rapeli@....fi,
dwmw2@...radead.org
Subject: Re: [PATCH v2 0/3] uapi glibc compat: fix musl libc compatibility
From: Hauke Mehrtens <hauke@...ke-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.
Powered by blists - more mailing lists