[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 7 May 2014 18:58:51 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: __xmknod, __sysv_signal
On Wed, May 07, 2014 at 05:18:30AM -0500, Rob Landley wrote:
> On 05/06/14 22:17, Rich Felker wrote:
> > On Tue, May 06, 2014 at 11:55:48AM -0500, M Farkas-Dyck wrote:
> >> What is musl's general policy on ABI compat? The FAQ says solely that
> >> "musl aims for a degree of feature-compatibility", not what degree. Is
> >> full binary compatibility with glibc the goal?
> >
> > While I don't think it's spelled out anywhere, the hope is to make it
> > so any strictly conforming POSIX program build against glibc also
> > works with musl dropped in. Programs using extensions that musl also
> > provides should work too. Programs using glibc features that musl does
> > not provide, or depending on glibc bugs, are not intended to be
> > supported.
> >
> >> If we mean to include such, we ought to choose where to keep the code first.
> >
> > Similar things are scattered here and there; see the junk in
> > src/ctype.
>
>
> Given that:
>
> #ifdef __MUSL__
> #include <gnuisms.h>
> #endif
>
> is off the table because musl is the platonic ideal C library, anonymous
There is no such ideological reason. As explained in the FAQ and many
times before, the reasons it's not provided are purly practical:
1. Every single time somebody has requested it, they were trying to do
something wrong, and in most case, what they were doing would have
broken support for subsequent versions of musl by hard-coding an
assumption that was about to become incorrect. (So, providing such a
macro would have left us getting the package fixed twice or more times
rather than just once, and would have made us look bad for "breaking
things" despite it being the package maintainer's fault.)
2. Hard-coding idiosynchracies of a particular platform is wrong
unless they are bugs that you know the platform has and which the
vendor has refused to fix (see: Windows), and which cannot be detected
at build time. In all other cases, the correct behavior is to detect,
either with configure-type checks, or with macros indicating the
presence of particular features/conformance profiles (like the
_POSIX_* macros from unistd.h).
> and infinite, and the idea of having musl-specific idiosynrasies that
> aren't necessarily considered the default (let alone building software
> for other libraries with 90% market share and wildly different behavior)
> will never come up in practice...
>
> There's a gnu extension called #include_next that lets you have a second
> set of headers inserted before the first set. It is, of course, a gnu
> extension.
>
> The library side seems easy enough to deal with via some sort of -lcrap
> added to the build, if you don't want it in libc itself.
>
> Or you could have a "./configure --legacy" to selectively enable this
> sort of stuff in libc.so and the headers, and then require people to use
> something like autoconf to determine whether or not this instance of
> libc was built with that because a #define would be coddling them.
This is useless. The symbols in question are ABI-only, not API. You
never use them when compiling new binaries. The only way the reference
to these symbols ever comes to exist is by virtue of glibc mess in
their headers and libc_nonshared.a, which redirects certain standard
functions to use these glibc-specific interfaces to libc.so rather
than just using the public names.
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.
