* __xmknod, __sysv_signal @ 2014-04-19 2:18 M Farkas-Dyck 2014-04-19 2:52 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: M Farkas-Dyck @ 2014-04-19 2:18 UTC (permalink / raw) To: musl A dynamic-linked binary blob I have wants these. Are these appropriate to include in musl? I have a patch ready. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-04-19 2:18 __xmknod, __sysv_signal M Farkas-Dyck @ 2014-04-19 2:52 ` Rich Felker 2014-04-19 3:11 ` M Farkas-Dyck 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2014-04-19 2:52 UTC (permalink / raw) To: musl On Fri, Apr 18, 2014 at 09:18:33PM -0500, M Farkas-Dyck wrote: > A dynamic-linked binary blob I have wants these. Are these appropriate > to include in musl? I have a patch ready. Send the patch and I'll review it. For __xmknod, I think this is just the ABI symbol glibc uses for mknod, and we could certainly add it (though I question whether there are any useful programs using it that couldn't just be rebuilt against musl). For __sysv_signal, I'm not sure what we should do. Its semantics are different from signal(), but it's doubtful that any program actually intended to request the sysv semantics (they're fundamentally broken and have race conditions that renders any program using them buggy) so it might just make more sense to have it be an alias for signal than to actually implement the broken sysv behavior. (Most likely is that glibc's weird behavior with certain feature test macros caused a program to inadvertently pull in the broken sysv version of signal rather than the default one.) Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-04-19 2:52 ` Rich Felker @ 2014-04-19 3:11 ` M Farkas-Dyck 2014-05-01 0:32 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: M Farkas-Dyck @ 2014-04-19 3:11 UTC (permalink / raw) To: musl On 18/04/2014, Rich Felker <dalias@libc.org> wrote: > For __xmknod, I think this is just the ABI symbol glibc uses for > mknod, and we could certainly add it (though I question whether there > are any useful programs using it that couldn't just be rebuilt against > musl). I wish to build ghc against musl, but it's like making yogurt: I need ghc to build ghc, and the ghc folks in their great wisdom distribute binaries... dynamic-linked against GNU turds. I myself doubt whether we ought to include them and pollute the ABI, but I thought that others might be in a like situation, which is why I ask. I am now using ghc with a locally-patched musl, so I hope to not need these symbols further myself, but the ultimate choice is yours. --- src/stat/__xmknod.c | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 src/stat/__xmknod.c diff --git a/src/stat/__xmknod.c b/src/stat/__xmknod.c new file mode 100644 index 0000000..62499de --- /dev/null +++ b/src/stat/__xmknod.c @@ -0,0 +1,6 @@ +#include <sys/stat.h> + +int __xmknod(int ver, const char *path, mode_t mode, dev_t *dev) +{ + return mknod (path, mode, dev); +} -- 1.8.5.2 --- src/signal/signal.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/signal/signal.c b/src/signal/signal.c index c0f063e..29e03c8 100644 --- a/src/signal/signal.c +++ b/src/signal/signal.c @@ -13,3 +13,4 @@ void (*signal(int sig, void (*func)(int)))(int) } weak_alias(signal, bsd_signal); +weak_alias(signal, __sysv_signal); -- 1.8.5.2 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-04-19 3:11 ` M Farkas-Dyck @ 2014-05-01 0:32 ` Rich Felker 2014-05-06 16:55 ` M Farkas-Dyck 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2014-05-01 0:32 UTC (permalink / raw) To: musl Sorry for taking a while to review this. I'd like to get it committed, but a few questions... On Fri, Apr 18, 2014 at 10:11:02PM -0500, M Farkas-Dyck wrote: > --- > src/stat/__xmknod.c | 6 ++++++ > 1 file changed, 6 insertions(+) > create mode 100644 src/stat/__xmknod.c > > diff --git a/src/stat/__xmknod.c b/src/stat/__xmknod.c > new file mode 100644 > index 0000000..62499de > --- /dev/null > +++ b/src/stat/__xmknod.c > @@ -0,0 +1,6 @@ > +#include <sys/stat.h> > + > +int __xmknod(int ver, const char *path, mode_t mode, dev_t *dev) > +{ > + return mknod (path, mode, dev); > +} I think this should be *dev or something; mknod takes dev_t, not dev_t*. Also I don't really like having this in src/stat, but we don't really have a dedicated place for ABI-compat junk yet... > --- > src/signal/signal.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/src/signal/signal.c b/src/signal/signal.c > index c0f063e..29e03c8 100644 > --- a/src/signal/signal.c > +++ b/src/signal/signal.c > @@ -13,3 +13,4 @@ void (*signal(int sig, void (*func)(int)))(int) > } > > weak_alias(signal, bsd_signal); > +weak_alias(signal, __sysv_signal); > -- > 1.8.5.2 Probably ok. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-05-01 0:32 ` Rich Felker @ 2014-05-06 16:55 ` M Farkas-Dyck 2014-05-07 3:17 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: M Farkas-Dyck @ 2014-05-06 16:55 UTC (permalink / raw) To: musl On 30/04/2014, Rich Felker <dalias@libc.org> wrote: > Sorry for taking a while to review this. I'd like to get it committed, > but a few questions... Ah, wasn't sure whether you meant to do this. >> +int __xmknod(int ver, const char *path, mode_t mode, dev_t *dev) >> +{ >> + return mknod (path, mode, dev); >> +} > > I think this should be *dev or something; mknod takes dev_t, not > dev_t*. Yes, that seems a typo in [1]. > Also I don't really like having this in src/stat, but we don't really > have a dedicated place for ABI-compat junk yet... I don't like it either. 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? If we mean to include such, we ought to choose where to keep the code first. [1] http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/baselib---xmknod-1.html ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-05-06 16:55 ` M Farkas-Dyck @ 2014-05-07 3:17 ` Rich Felker 2014-05-07 10:18 ` Rob Landley 0 siblings, 1 reply; 8+ messages in thread From: Rich Felker @ 2014-05-07 3:17 UTC (permalink / raw) To: musl 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. Rich ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-05-07 3:17 ` Rich Felker @ 2014-05-07 10:18 ` Rob Landley 2014-05-07 22:58 ` Rich Felker 0 siblings, 1 reply; 8+ messages in thread From: Rob Landley @ 2014-05-07 10:18 UTC (permalink / raw) To: musl, dalias 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 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. Rob ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: __xmknod, __sysv_signal 2014-05-07 10:18 ` Rob Landley @ 2014-05-07 22:58 ` Rich Felker 0 siblings, 0 replies; 8+ messages in thread From: Rich Felker @ 2014-05-07 22:58 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2014-05-07 22:58 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-04-19 2:18 __xmknod, __sysv_signal M Farkas-Dyck 2014-04-19 2:52 ` Rich Felker 2014-04-19 3:11 ` M Farkas-Dyck 2014-05-01 0:32 ` Rich Felker 2014-05-06 16:55 ` M Farkas-Dyck 2014-05-07 3:17 ` Rich Felker 2014-05-07 10:18 ` Rob Landley 2014-05-07 22:58 ` Rich Felker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).