From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9441 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: iproute2 & other software Date: Wed, 2 Mar 2016 21:49:41 +0100 Message-ID: <20160302204941.GH29662@port70.net> References: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1456951803 13378 80.91.229.3 (2 Mar 2016 20:50:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 2 Mar 2016 20:50:03 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9454-gllmg-musl=m.gmane.org@lists.openwall.com Wed Mar 02 21:50:03 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1abDiV-0001zT-H6 for gllmg-musl@m.gmane.org; Wed, 02 Mar 2016 21:49:55 +0100 Original-Received: (qmail 16354 invoked by uid 550); 2 Mar 2016 20:49:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 16336 invoked from network); 2 Mar 2016 20:49:53 -0000 Mail-Followup-To: musl@lists.openwall.com Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9441 Archived-At: * Loganaden Velvindron [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