* [musl] Re: OS detection wrong on Alpine Linux 3.10 [not found] <4768019.hHWyC0TzgU@omega> @ 2020-09-20 10:12 ` Dmitry V. Levin 2020-09-20 11:19 ` Bruno Haible 2020-09-20 12:19 ` Ariadne Conill 0 siblings, 2 replies; 23+ messages in thread From: Dmitry V. Levin @ 2020-09-20 10:12 UTC (permalink / raw) To: Bruno Haible; +Cc: config-patches, musl On Sat, Sep 19, 2020 at 03:30:54PM +0200, Bruno Haible wrote: > The value of $host_os, determined by the current config.guess, is: > - On Alpine Linux 3.9: linux-musl > - On Alpine Linux 3.10: linux-gnu > - On Alpine Linux 3.12: linux-musl > > The reason is that config.guess tests 'ldd --version'. However, in > Alpine Linux 3.10, /usr/bin/ldd has been replaced with a shell script > that does not understand the --version option: > > $ cat /usr/bin/ldd > #!/bin/sh > exec /lib/ld-musl-x86_64.so.1 --list -- "$@" > $ /usr/bin/ldd --version 2>&1 > /lib/ld-musl-x86_64.so.1: cannot load --version: No such file or directory > > Find attached a proposed fix. More details in > <https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00098.html>. > > Bruno > >From 6e8da56c68ad94175d67acfc6257e614fe74e01d Mon Sep 17 00:00:00 2001 > From: Bruno Haible <bruno@clisp.org> > Date: Sat, 19 Sep 2020 15:24:59 +0200 > Subject: [PATCH] * config.guess: Fix determination of musl libc on Alpine > Linux 3.10. > > --- > ChangeLog | 5 +++++ > config.guess | 14 ++++++-------- > 2 files changed, 11 insertions(+), 8 deletions(-) > > diff --git a/ChangeLog b/ChangeLog > index 4f106db..834f4e5 100644 > --- a/ChangeLog > +++ b/ChangeLog > @@ -1,3 +1,8 @@ > +2020-09-19 Bruno Haible <bruno@clisp.org> > + > + * config.guess: Don't use 'ldd --version' to determine the presence of > + musl libc, as this fails on Alpine Linux 3.10. > + > 2020-09-08 Elad Lahav <e2lahav@gmail.com> > Ben Elliston <bje@gnu.org> > > diff --git a/config.guess b/config.guess > index 9aff91c..8d70ec2 100755 > --- a/config.guess > +++ b/config.guess > @@ -2,7 +2,7 @@ > # Attempt to guess a canonical system name. > # Copyright 1992-2020 Free Software Foundation, Inc. > > -timestamp='2020-08-17' > +timestamp='2020-09-19' > > # This file is free software; you can redistribute it and/or modify it > # under the terms of the GNU General Public License as published by > @@ -150,17 +150,15 @@ Linux|GNU|GNU/*) > #elif defined(__dietlibc__) > LIBC=dietlibc > #else > + #include <stdarg.h> > + #ifdef __DEFINED_va_list > + LIBC=musl > + #else > LIBC=gnu > #endif > + #endif > EOF > eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^LIBC' | sed 's, ,,g'`" > - > - # If ldd exists, use it to detect musl libc. > - if command -v ldd >/dev/null && \ > - ldd --version 2>&1 | grep -q ^musl > - then > - LIBC=musl > - fi > ;; > esac > Is this __DEFINED_va_list macro the official way of detecting musl? It looks very fragile to me. -- ldv ^ permalink raw reply [flat|nested] 23+ messages in thread
* [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 10:12 ` [musl] Re: OS detection wrong on Alpine Linux 3.10 Dmitry V. Levin @ 2020-09-20 11:19 ` Bruno Haible 2020-09-20 12:18 ` Ariadne Conill 2020-09-20 13:56 ` Szabolcs Nagy 2020-09-20 12:19 ` Ariadne Conill 1 sibling, 2 replies; 23+ messages in thread From: Bruno Haible @ 2020-09-20 11:19 UTC (permalink / raw) To: Dmitry V. Levin; +Cc: config-patches, musl [-- Attachment #1: Type: text/plain, Size: 791 bytes --] Dmitry V. Levin wrote: > Is this __DEFINED_va_list macro the official way of detecting musl? No, but in a world where the musl people don't want to provide an official way [1][2] and the Alpine Linux people break their previously working way of detecting musl [3], we (GNU) need to use our own heuristics to fulfil the practical need of programs (especially test suites) to distinguish musl systems from glibc systems. > It looks very fragile to me. Indeed, config.guess would be less fragile if we combined both heuristics. Patch attached. It's a trade-off between code size and robustness. Bruno [1] https://wiki.musl-libc.org/faq.html [2] https://lists.gnu.org/archive/html/bug-gnulib/2018-02/msg00079.html [3] https://lists.gnu.org/archive/html/config-patches/2020-09/msg00002.html [-- Attachment #2: 0001-config.guess-Combine-two-heuristics-to-detect-musl-l.patch --] [-- Type: text/x-patch, Size: 1637 bytes --] From 78ceae822bde047eea1db841a5feeba94f57fe7d Mon Sep 17 00:00:00 2001 From: Bruno Haible <bruno@clisp.org> Date: Sun, 20 Sep 2020 13:17:12 +0200 Subject: [PATCH] * config.guess: Combine two heuristics to detect musl libc. Reported by Dmitry V. Levin. --- ChangeLog | 5 +++++ config.guess | 10 +++++++++- 2 files changed, 14 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index 834f4e5..63101b8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,8 @@ +2020-09-20 Bruno Haible <bruno@clisp.org> + + * config.guess: Combine two heuristics to detect musl libc. + Reported by Dmitry V. Levin. + 2020-09-19 Bruno Haible <bruno@clisp.org> * config.guess: Don't use 'ldd --version' to determine the presence of diff --git a/config.guess b/config.guess index 8d70ec2..cd8a0a3 100755 --- a/config.guess +++ b/config.guess @@ -2,7 +2,7 @@ # Attempt to guess a canonical system name. # Copyright 1992-2020 Free Software Foundation, Inc. -timestamp='2020-09-19' +timestamp='2020-09-20' # This file is free software; you can redistribute it and/or modify it # under the terms of the GNU General Public License as published by @@ -151,6 +151,7 @@ Linux|GNU|GNU/*) LIBC=dietlibc #else #include <stdarg.h> + /* First heuristic to detect musl libc. */ #ifdef __DEFINED_va_list LIBC=musl #else @@ -159,6 +160,13 @@ Linux|GNU|GNU/*) #endif EOF eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^LIBC' | sed 's, ,,g'`" + + # Second heuristic to detect musl libc. + if command -v ldd >/dev/null && \ + ldd --version 2>&1 | grep -q ^musl + then + LIBC=musl + fi ;; esac -- 2.7.4 ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 11:19 ` Bruno Haible @ 2020-09-20 12:18 ` Ariadne Conill 2020-09-20 13:56 ` Szabolcs Nagy 1 sibling, 0 replies; 23+ messages in thread From: Ariadne Conill @ 2020-09-20 12:18 UTC (permalink / raw) To: musl, Bruno Haible, Dmitry V. Levin; +Cc: config-patches Hello, On 2020-09-20 05:19, Bruno Haible wrote: > Dmitry V. Levin wrote: >> Is this __DEFINED_va_list macro the official way of detecting musl? > > No, but in a world where the musl people don't want to provide an official > way [1][2] and the Alpine Linux people break their previously working way of > detecting musl [3], we (GNU) need to use our own heuristics to fulfil the > practical need of programs (especially test suites) to distinguish musl > systems from glibc systems. Actually, it was a bug, and only affects Alpine Linux 3.10.0. Any 3.10.x release newer than that will work just fine with the pre-existing checks. I don't really think it is necessary to have this check, as the likelihood of anyone building GNU software by hand on Alpine Linux 3.10.0 at this point is low. Ariadne ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 11:19 ` Bruno Haible 2020-09-20 12:18 ` Ariadne Conill @ 2020-09-20 13:56 ` Szabolcs Nagy 2020-09-20 17:14 ` Rich Felker 1 sibling, 1 reply; 23+ messages in thread From: Szabolcs Nagy @ 2020-09-20 13:56 UTC (permalink / raw) To: Bruno Haible; +Cc: Dmitry V. Levin, config-patches, musl * Bruno Haible <bruno@clisp.org> [2020-09-20 13:19:13 +0200]: > Dmitry V. Levin wrote: > > Is this __DEFINED_va_list macro the official way of detecting musl? > > No, but in a world where the musl people don't want to provide an official > way [1][2] and the Alpine Linux people break their previously working way of > detecting musl [3], we (GNU) need to use our own heuristics to fulfil the > practical need of programs (especially test suites) to distinguish musl > systems from glibc systems. we have not seen a "practical need of programs to distinguish musl systems from glibc systems". instead we have seen a practical need to detect specific c runtime behaviours and extensions. even in the glibc world using __GLIBC__ to detect features is not reliable since there are heavily patched glibcs out there. (though the way glibc handles api and abi stability means it mostly works, but this is unreasonable to expect across different implementations) ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 13:56 ` Szabolcs Nagy @ 2020-09-20 17:14 ` Rich Felker 2020-09-20 19:21 ` Bruno Haible 0 siblings, 1 reply; 23+ messages in thread From: Rich Felker @ 2020-09-20 17:14 UTC (permalink / raw) To: Bruno Haible, Dmitry V. Levin, config-patches, musl On Sun, Sep 20, 2020 at 03:56:29PM +0200, Szabolcs Nagy wrote: > * Bruno Haible <bruno@clisp.org> [2020-09-20 13:19:13 +0200]: > > Dmitry V. Levin wrote: > > > Is this __DEFINED_va_list macro the official way of detecting musl? > > > > No, but in a world where the musl people don't want to provide an official > > way [1][2] and the Alpine Linux people break their previously working way of > > detecting musl [3], we (GNU) need to use our own heuristics to fulfil the > > practical need of programs (especially test suites) to distinguish musl > > systems from glibc systems. > > we have not seen a "practical need of programs > to distinguish musl systems from glibc systems". > > instead we have seen a practical need to detect > specific c runtime behaviours and extensions. > > even in the glibc world using __GLIBC__ to detect > features is not reliable since there are heavily > patched glibcs out there. (though the way glibc > handles api and abi stability means it mostly > works, but this is unreasonable to expect across > different implementations) There is one kinda legitimate purpose for detecting specifically musl: when setting $target to match $host for the purpose of a host-targeting compiler toolchain. That does not seem to be the topic at hand here, though. Please note that __DEFINED_* are bits/alltypes.h-internal macros, and are not public interfaces for detecting musl or definition status of any particular type. They are not even "public within musl" -- i.e. musl source files or public headers outside bits/alltypes.h are not allowed to use or poke at them. Their naming or the entire mechanism is subject to change at any time. Rich ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 17:14 ` Rich Felker @ 2020-09-20 19:21 ` Bruno Haible 2020-09-20 20:58 ` Hadrien Lacour ` (2 more replies) 0 siblings, 3 replies; 23+ messages in thread From: Bruno Haible @ 2020-09-20 19:21 UTC (permalink / raw) To: Rich Felker; +Cc: Dmitry V. Levin, config-patches, musl Rich, POSIX — like many other standard — allows different implementations to behave differently. For example, iconv_open() and setlocale() behave differently in different POSIX-compliant libc implementations. This is OK. There is nothing wrong with it on either side. Unit tests [1] need to take into account the actual behaviour of the software. It is normal that a unit test's core function produces a different result with musl than with glibc. The "expected outcome" part of the unit test, in this case, needs to be different. This is an actual, practical need to know whether the config triple ends in linux-gnu vs. linux-musl. > There is one kinda legitimate purpose for detecting specifically musl: It is not your role to tell us which code we write is "legitimate" and which code is not. I am a grown-up programmer. Bruno [1] https://en.wikipedia.org/wiki/Unit_testing ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 19:21 ` Bruno Haible @ 2020-09-20 20:58 ` Hadrien Lacour 2020-09-21 6:53 ` A. Wilcox 2020-09-22 18:46 ` Rich Felker 2 siblings, 0 replies; 23+ messages in thread From: Hadrien Lacour @ 2020-09-20 20:58 UTC (permalink / raw) To: musl On Sun, Sep 20, 2020 at 09:21:48PM +0200, Bruno Haible wrote: > Rich, > > POSIX — like many other standard — allows different implementations to > behave differently. For example, iconv_open() and setlocale() behave > differently in different POSIX-compliant libc implementations. This is > OK. There is nothing wrong with it on either side. > > Unit tests [1] need to take into account the actual behaviour of the > software. It is normal that a unit test's core function produces a > different result with musl than with glibc. The "expected outcome" > part of the unit test, in this case, needs to be different. This is > an actual, practical need to know whether the config triple ends in > linux-gnu vs. linux-musl. > > > There is one kinda legitimate purpose for detecting specifically musl: > > It is not your role to tell us which code we write is "legitimate" and > which code is not. I am a grown-up programmer. > > Bruno > > [1] https://en.wikipedia.org/wiki/Unit_testing > Sorry to waltz in like this but isn't it bad practice in general to rely on implementation-defined behaviours? ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 19:21 ` Bruno Haible 2020-09-20 20:58 ` Hadrien Lacour @ 2020-09-21 6:53 ` A. Wilcox 2020-09-21 11:46 ` Florian Weimer 2020-09-22 18:46 ` Rich Felker 2 siblings, 1 reply; 23+ messages in thread From: A. Wilcox @ 2020-09-21 6:53 UTC (permalink / raw) To: musl [-- Attachment #1.1: Type: text/plain, Size: 2479 bytes --] On 20/09/2020 14:21, Bruno Haible wrote: > Rich, > > POSIX — like many other standard — allows different implementations to > behave differently. For example, iconv_open() and setlocale() behave > differently in different POSIX-compliant libc implementations. This is > OK. There is nothing wrong with it on either side. > > Unit tests [1] need to take into account the actual behaviour of the > software. It is normal that a unit test's core function produces a > different result with musl than with glibc. The "expected outcome" > part of the unit test, in this case, needs to be different. This is > an actual, practical need to know whether the config triple ends in > linux-gnu vs. linux-musl. And then the tests break when glibc changes behaviour from one POSIX conformant way to the other. Or when musl changes behaviour. etc. As a distro packager: this sucks. Don't do it. Seriously. Do not do it. If a downstream needs to care about a behaviour of setlocale, they can write an autoconf macro testing the behaviour, and then use that. Then when glibc and/or musl and/or FreeBSD and/or $platform_of_the_week changes its behaviour, the test suite still passes without me having to dive into horrible m4 code and making me extremely angry for a week. I have seen this happen way too often, and it is always in GNU packages, because you lot seem to think that libraries exist in a microcosm of spacetime where their behaviours are static forever. System libraries evolve. They evolve slower than others, but still a non-zero rate. Note that there are plenty of GNU packages that actually use autotools correctly, and they are a breath of fresh air, and they do not make me afraid of building them. Learn from them. Be more like them. >> There is one kinda legitimate purpose for detecting specifically musl: > > It is not your role to tell us which code we write is "legitimate" and > which code is not. I am a grown-up programmer. Apparently not, or you would realise what you are doing is wrong, and hurts your projects by making them infinitely harder to build than they really need to be. And that hurts you, and us (distros), and the people who *use* your software. Please, test behaviours, not library types. Best, --arw > > Bruno > > [1] https://en.wikipedia.org/wiki/Unit_testing > -- A. Wilcox (awilfox) Project Lead, Adélie Linux https://www.adelielinux.org [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-21 6:53 ` A. Wilcox @ 2020-09-21 11:46 ` Florian Weimer 0 siblings, 0 replies; 23+ messages in thread From: Florian Weimer @ 2020-09-21 11:46 UTC (permalink / raw) To: A. Wilcox; +Cc: musl * A. Wilcox: > If a downstream needs to care about a behaviour of setlocale, they can > write an autoconf macro testing the behaviour, and then use that. Then > when glibc and/or musl and/or FreeBSD and/or $platform_of_the_week > changes its behaviour, the test suite still passes without me having to > dive into horrible m4 code and making me extremely angry for a week. If it's a run-time property, it should really be a run-time check, otherwise cross-compilers will break. There are things that are not open to run-time checks, though, like the presence of symbol versioning support in the dynamic loader. Ideally, musl applications would be built with a toolchain that completely lacks symbol versioning support, but that's not what happens in practice. Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 19:21 ` Bruno Haible 2020-09-20 20:58 ` Hadrien Lacour 2020-09-21 6:53 ` A. Wilcox @ 2020-09-22 18:46 ` Rich Felker 2020-09-22 20:18 ` Bruno Haible 2020-09-22 20:39 ` Jeffrey Walton 2 siblings, 2 replies; 23+ messages in thread From: Rich Felker @ 2020-09-22 18:46 UTC (permalink / raw) To: Bruno Haible; +Cc: Dmitry V. Levin, config-patches, musl On Sun, Sep 20, 2020 at 09:21:48PM +0200, Bruno Haible wrote: > Rich, > > POSIX — like many other standard — allows different implementations to > behave differently. For example, iconv_open() and setlocale() behave > differently in different POSIX-compliant libc implementations. This is > OK. There is nothing wrong with it on either side. > > Unit tests [1] need to take into account the actual behaviour of the > software. It is normal that a unit test's core function produces a > different result with musl than with glibc. The "expected outcome" > part of the unit test, in this case, needs to be different. This is > an actual, practical need to know whether the config triple ends in > linux-gnu vs. linux-musl. > > > There is one kinda legitimate purpose for detecting specifically musl: > > It is not your role to tell us which code we write is "legitimate" and > which code is not. I am a grown-up programmer. I'm not trying to tell you you're not a grown-up programmer. I'm trying to tell you that the answer to the question you're asking ("is this musl?") is not meaningful for achieving what you presumably want to achieve -- assisting the program using autoconf tests in automatically producing a build that works on the intended host. It's true that implementations have a number of things that are implementation defined, and that the standards specify this as having a documented behavior (which the party reading the documentation can then rely upon). At present musl does not have sufficient documentation in this regard; I began the work of enumerating all the impl-defined behaviors at one point with a goal of documenting them but it was never completed. However, more fundamentally, the notion of "the implementation", in this sense, is specific to one particular version, along with whatever distributor-applied or user-applied patches might be present. That is to say, some of the implementation-defined behaviors may *change between versions* in ways that render a hard-coded assumption that "musl does X" wrong when building against a newer version or even just running against a newer version (assuming dynamic linking). As such, in general, it is specifically NOT SUPPORTED USAGE to hard-code these kinds of things. This has been documented in various places (mailing list, wiki, etc.) over the project's lifetime but should really be written up well as part of the formal documentation. Instead, it's our intent (i.e. musl's supported way of interfacing with implementation-defined behavior) that programs intending to rely on properties that are not well-defined across different implementations should have their build systems perform the appropriate fine-grained tests for what they need to know. Trying to improve the ability for build systems to do this, especially in the cross-compiling case and cases where the test itself would invoke UB, is the topic of this thread on libc-coord: https://www.openwall.com/lists/libc-coord/2020/04/22/1 Rich ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-22 18:46 ` Rich Felker @ 2020-09-22 20:18 ` Bruno Haible 2020-09-22 20:33 ` Jeffrey Walton 2020-09-22 20:39 ` Jeffrey Walton 1 sibling, 1 reply; 23+ messages in thread From: Bruno Haible @ 2020-09-22 20:18 UTC (permalink / raw) To: Rich Felker; +Cc: Dmitry V. Levin, musl [Dropping config-patches from CC.] Hi Rich, > I'm not trying to tell you you're not a grown-up programmer. I'm > trying to tell you that the answer to the question you're asking ("is > this musl?") is not meaningful Good. Then maybe the term "legitimate" was too strong... > It's true that implementations have a number of things that are > implementation defined, and that the standards specify this as having > a documented behavior (which the party reading the documentation can > then rely upon). At present musl does not have sufficient > documentation in this regard; I began the work of enumerating all the > impl-defined behaviors at one point with a goal of documenting them > but it was never completed. It is good to attempt to document such things. But I doubt anyone can ever produce a complete documentation of this kind: * For many system calls, when POSIX specifies an errno X for condition A, and an errno Y for condition B, then if both A and B apply, often the implementation is free to return errno X or Y. There are many system calls and many possible combinations of conditions... * Is a certain function call multithread-safe or not? For example, setlocale (..., NULL) is multithread-safe in glibc, but not in musl libc, macOS, and other platforms. [1] I know that setlocale is not MT-safe in POSIX, but nevertheless it is useful for threads in multithreaded programs (that don't use uselocale()) to be able to query the current locale. * For iconv(), different platforms implement the conversions slightly differently [2]. The complete documentation would have to include the conversion tables (huge!). > However, more fundamentally, the notion of "the implementation", in > this sense, is specific to one particular version, along with whatever > distributor-applied or user-applied patches might be present. That is > to say, some of the implementation-defined behaviors may *change > between versions* in ways that render a hard-coded assumption that > "musl does X" wrong when building against a newer version or even just > running against a newer version (assuming dynamic linking). Correct. And my unit tests may start to fail in this scenario, and I'm willing to accept this. Unit tests are different than production code in various ways. One aspect is the notion of "expected outcome". If a test has a different expected outcome on glibc than on musl — due to implementation-defined or implementation-dependent but undocumented behaviour — and suddenly on glibc systems the outcome changes from the glibc outcome to the musl outcome, I *do* want to know about it. Even though both outcomes are valid, a change in outcome potentially indicates a problem. That is the rationale for distinguishing musl from glibc in a test suite. And an autoconf test wouldn't help here — because it would just classify glibc on the other side and not alert me of the potential problem. > As such, in general, it is specifically NOT SUPPORTED USAGE to hard-code > these kinds of things. This has been documented in various places Fair enough. But as a test suite maintainer, my judgement is that it is more useful to make these "NOT SUPPORTED" distinctions than to allow the musl behaviour to occur on glibc systems and vice versa. Bruno [1] Test case: https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=tests/test-setlocale_null-mt-all.c [2] https://haible.de/bruno/charsets/conversion-tables/ ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-22 20:18 ` Bruno Haible @ 2020-09-22 20:33 ` Jeffrey Walton 0 siblings, 0 replies; 23+ messages in thread From: Jeffrey Walton @ 2020-09-22 20:33 UTC (permalink / raw) To: musl On Tue, Sep 22, 2020 at 4:18 PM Bruno Haible <bruno@clisp.org> wrote: > ... > > It's true that implementations have a number of things that are > > implementation defined, and that the standards specify this as having > > a documented behavior (which the party reading the documentation can > > then rely upon). At present musl does not have sufficient > > documentation in this regard; I began the work of enumerating all the > > impl-defined behaviors at one point with a goal of documenting them > > but it was never completed. > > It is good to attempt to document such things. But I doubt anyone can > ever produce a complete documentation of this kind: > > * For many system calls, when POSIX specifies an errno X for condition A, > and an errno Y for condition B, then if both A and B apply, often > the implementation is free to return errno X or Y. There are many > system calls and many possible combinations of conditions... Not to mention SELinux hijacking error codes and errno so you go chasing the wrong cause of an error... Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-22 18:46 ` Rich Felker 2020-09-22 20:18 ` Bruno Haible @ 2020-09-22 20:39 ` Jeffrey Walton 2020-09-22 21:04 ` Laurent Bercot 1 sibling, 1 reply; 23+ messages in thread From: Jeffrey Walton @ 2020-09-22 20:39 UTC (permalink / raw) To: musl; +Cc: Bruno Haible, Dmitry V. Levin, config-patches On Tue, Sep 22, 2020 at 2:46 PM Rich Felker <dalias@libc.org> wrote: > ... > > > There is one kinda legitimate purpose for detecting specifically musl: > > > > It is not your role to tell us which code we write is "legitimate" and > > which code is not. I am a grown-up programmer. > > I'm not trying to tell you you're not a grown-up programmer. I'm > trying to tell you that the answer to the question you're asking ("is > this musl?") is not meaningful for achieving what you presumably want > to achieve -- assisting the program using autoconf tests in > automatically producing a build that works on the intended host. That assumes a project is Autotools based. I know of at least four projects that don't use Autotools (or other similar programs) because they don't want the dependency (and problems that come with the dependency). Speaking from experience, Autotools is a mess, especially for C++ projects. I would not wish it on an enemy. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-22 20:39 ` Jeffrey Walton @ 2020-09-22 21:04 ` Laurent Bercot 2020-09-22 21:17 ` Jeffrey Walton 0 siblings, 1 reply; 23+ messages in thread From: Laurent Bercot @ 2020-09-22 21:04 UTC (permalink / raw) To: musl >> I'm not trying to tell you you're not a grown-up programmer. I'm >> trying to tell you that the answer to the question you're asking ("is >> this musl?") is not meaningful for achieving what you presumably want >> to achieve -- assisting the program using autoconf tests in >> automatically producing a build that works on the intended host. > >That assumes a project is Autotools based. No, it does not. It assumes that the project's authors are attempting to produce a working project, including detection of implementation- defined behaviour wherever the project relies on them. "autoconf tests" is a shortcut that means "tests performed at build time that do such detection", because autoconf is the most widely known program that produces such tests and everyone understands the expression. But it doesn't mean that a project has to use autotools. My projects don't, and never will; however, they do perform feature detection at build time, because it's necessary for what they do. If a project relies on implementation-defined behaviour and does not perform detection, then it is broken and needs to be fixed. If its build system does not allow it to perform detection, then it needs to switch to a better build system. As you say, autotools is a mess, but it at least gets this part right (more or less - it does cross-building wrong because by default it assumes target behaviours it cannot detect, instead of asking the user). I very much hope other build systems are capable of doing the same. If not, that's, for once, functionality they should grow, because it's useful. -- Laurent ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-22 21:04 ` Laurent Bercot @ 2020-09-22 21:17 ` Jeffrey Walton 2020-09-23 8:49 ` Laurent Bercot 0 siblings, 1 reply; 23+ messages in thread From: Jeffrey Walton @ 2020-09-22 21:17 UTC (permalink / raw) To: musl On Tue, Sep 22, 2020 at 5:11 PM Laurent Bercot <ska-dietlibc@skarnet.org> wrote: > > >> I'm not trying to tell you you're not a grown-up programmer. I'm > >> trying to tell you that the answer to the question you're asking ("is > >> this musl?") is not meaningful for achieving what you presumably want > >> to achieve -- assisting the program using autoconf tests in > >> automatically producing a build that works on the intended host. > > > >That assumes a project is Autotools based. > > No, it does not. It assumes that the project's authors are attempting > to produce a working project, including detection of implementation- > defined behaviour wherever the project relies on them. "autoconf tests" > is a shortcut that means "tests performed at build time that do such > detection", because autoconf is the most widely known program that > produces such tests and everyone understands the expression. No, I said "Autotools (or other similar programs)". All I need is GNU Make and preprocessor macros. It is a marriage made in heaven. I don't want or need a configuration program. A configuration program is another point of failure. It causes mailing list messages and bug reports for me. I don't want to waste my time with them. > But it doesn't mean that a project has to use autotools. My projects > don't, and never will; however, they do perform feature detection at > build time, because it's necessary for what they do. > > If a project relies on implementation-defined behaviour and does not > perform detection, then it is broken and needs to be fixed. If its > build system does not allow it to perform detection, then it needs to > switch to a better build system. Again, your opinion. I have build systems that work perfectly except when I have to jump through hoops for Musl. You are trying to set policy for me. (That's what Bruno said earlier, in not so many words). Don't do that. All I need to know is what version of Musl I am dealing with and I can configure myself. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-22 21:17 ` Jeffrey Walton @ 2020-09-23 8:49 ` Laurent Bercot 2020-09-23 13:13 ` James Y Knight 0 siblings, 1 reply; 23+ messages in thread From: Laurent Bercot @ 2020-09-23 8:49 UTC (permalink / raw) To: musl >All I need is GNU Make and preprocessor macros. It is a marriage made in heaven. That works until you rely on features you cannot detect at compile time. Example: the presence of a flock(), memmem(), or getpeereid() function. If you're only writing for Linux, you can generally get by, more or less, with preprocessor macros and duct tape. If you're attempting to write portable programs, however, you can run into a wall very fast. >> If a project relies on implementation-defined behaviour and does not >> perform detection, then it is broken and needs to be fixed. If its >> build system does not allow it to perform detection, then it needs to >> switch to a better build system. > >Again, your opinion. It's really not. I did *not* enjoy writing my own configure scripts, I would gladly have relied on preprocessor macros like a lot of projects out there. Unfortunately, it soon appeared that doing so would not be enough to meet my requirements of portability and correctness, and that performing feature detection was a necessary evil. My opinion, if you want to know it, is that it's a failure of operating systems to have diverged that much and force programmers to jump through hoops in order to be compatible across them, and that we are collectively paying the price (technical debt) of commercial-based and ego-based decisions. I hate it, but it's not in my power to change it, and I have to adapt. And if I don't, the people who package my software for various distributions will have to do the work for me; and they're overloaded enough as is. > I have build systems that work perfectly except >when I have to jump through hoops for Musl. That's a common misconception. The reality is that you have been vendor-locked-in and lulled into a false sense of correctness; and when porting your programs to musl, you are experiencing trouble because of your reliance on proprietary (in spirit) extensions and behaviours that musl does not match. Do your programs also work perfectly, without patching, on various BSDs? on MacOS? on Solaris? Do they work perfectly when cross-building? Don't blame this on musl; blame it on the system that locked you in and gave you bad habits. >You are trying to set policy for me. I'm being purely descriptive, and am only setting the necessary policies for building correct, cross-buildable, portable projects. >All I need to know is what version of Musl I am dealing with and I can >configure myself. Are you willing to maintain an #ifdef forest for all the versions of all the libcs and all the kernels your programs may be used with, so you can list exhaustively the available features in every configuration? Because that's where your model leads. ;) -- Laurent ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-23 8:49 ` Laurent Bercot @ 2020-09-23 13:13 ` James Y Knight 2020-09-23 16:08 ` Rich Felker 0 siblings, 1 reply; 23+ messages in thread From: James Y Knight @ 2020-09-23 13:13 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 663 bytes --] > > >All I need to know is what version of Musl I am dealing with and I can > >configure myself. > > Are you willing to maintain an #ifdef forest for all the versions of > all the libcs and all the kernels your programs may be used with, so > you can list exhaustively the available features in every configuration? > At the risk of jumping in on a question asked of someone else: yes, absolutely! (Not _all_ available features of course, just the ones required.) There are generally not that many nonstandard features you'd want to use in a typical program, and using an ifdef forest to implement an abstraction layer around those couple items is just fine. [-- Attachment #2: Type: text/html, Size: 960 bytes --] ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-23 13:13 ` James Y Knight @ 2020-09-23 16:08 ` Rich Felker 2020-09-23 16:16 ` Jeffrey Walton 0 siblings, 1 reply; 23+ messages in thread From: Rich Felker @ 2020-09-23 16:08 UTC (permalink / raw) To: James Y Knight; +Cc: musl On Wed, Sep 23, 2020 at 09:13:16AM -0400, James Y Knight wrote: > > > > >All I need to know is what version of Musl I am dealing with and I can > > >configure myself. > > > > Are you willing to maintain an #ifdef forest for all the versions of > > all the libcs and all the kernels your programs may be used with, so > > you can list exhaustively the available features in every configuration? > > > > At the risk of jumping in on a question asked of someone else: yes, > absolutely! (Not _all_ available features of course, just the ones > required.) > > There are generally not that many nonstandard features you'd want to use in > a typical program, and using an ifdef forest to implement an abstraction > layer around those couple items is just fine. I can't know whether you're "willing", but you're definitely not willing and able. "All the..." includes people's personal projects (from scratch or patches to existing ones) that you will never see, future systems that come into existence long past your involvement in the project or even your lifetime, etc. There is simply fundamentally no way to maintain and guarantee compatibility with an unbounded, as-yet-unknown set of standards-conforming systems short of either (1) only using the standard-specified properties, or (2) testing for any non-standard-specified properties you want to use. As for "willing", most people who say they're willing to do this are actually only willing to do it for the 3-5 most popular systems at the time they work on the project; they never even hear about problems they created on all the other minority systems since the few affected users tend to assume (accurately, most often) that an upstream that thinks it's ok to hard-code #ifdef-trees won't care about supporting them. Rich ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-23 16:08 ` Rich Felker @ 2020-09-23 16:16 ` Jeffrey Walton 2020-09-23 16:26 ` Ariadne Conill 2020-09-23 16:36 ` Rich Felker 0 siblings, 2 replies; 23+ messages in thread From: Jeffrey Walton @ 2020-09-23 16:16 UTC (permalink / raw) To: musl On Wed, Sep 23, 2020 at 12:08 PM Rich Felker <dalias@libc.org> wrote: > > On Wed, Sep 23, 2020 at 09:13:16AM -0400, James Y Knight wrote: > > > > > > >All I need to know is what version of Musl I am dealing with and I can > > > >configure myself. > > > > > > Are you willing to maintain an #ifdef forest for all the versions of > > > all the libcs and all the kernels your programs may be used with, so > > > you can list exhaustively the available features in every configuration? > > > > At the risk of jumping in on a question asked of someone else: yes, > > absolutely! (Not _all_ available features of course, just the ones > > required.) > > > > There are generally not that many nonstandard features you'd want to use in > > a typical program, and using an ifdef forest to implement an abstraction > > layer around those couple items is just fine. > > I can't know whether you're "willing", but you're definitely not > willing and able. "All the..." includes people's personal projects > (from scratch or patches to existing ones) that you will never see, > future systems that come into existence long past your involvement in > the project or even your lifetime, etc. Unless something has changed recently, Botan, Crypto++ and OpenSSL are still being carried by most Linux distributions. OpenSSL is also regularly distributed as part of other OSes, like AIX, Android, BSDs, iOS, OS X and Solaris. And unlike some other projects,[1] Botan, Crypto++ and OpenSSL actually work in practice on all the platforms without a configuration program that performs feature tests. [1] the Rust compiler comes to mind here. It works on Linux x86_64, but it's hit or miss whether it works or not on other architectures like ARMv7, Aarch64 and PowerPC, even after an approved configuration program is run. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-23 16:16 ` Jeffrey Walton @ 2020-09-23 16:26 ` Ariadne Conill 2020-09-23 16:57 ` Jeffrey Walton 2020-09-23 16:36 ` Rich Felker 1 sibling, 1 reply; 23+ messages in thread From: Ariadne Conill @ 2020-09-23 16:26 UTC (permalink / raw) To: musl, Jeffrey Walton Hello, On 2020-09-23 10:16, Jeffrey Walton wrote: > On Wed, Sep 23, 2020 at 12:08 PM Rich Felker <dalias@libc.org> wrote: >> >> On Wed, Sep 23, 2020 at 09:13:16AM -0400, James Y Knight wrote: >>>> >>>>> All I need to know is what version of Musl I am dealing with and I can >>>>> configure myself. >>>> >>>> Are you willing to maintain an #ifdef forest for all the versions of >>>> all the libcs and all the kernels your programs may be used with, so >>>> you can list exhaustively the available features in every configuration? >>> >>> At the risk of jumping in on a question asked of someone else: yes, >>> absolutely! (Not _all_ available features of course, just the ones >>> required.) >>> >>> There are generally not that many nonstandard features you'd want to use in >>> a typical program, and using an ifdef forest to implement an abstraction >>> layer around those couple items is just fine. >> >> I can't know whether you're "willing", but you're definitely not >> willing and able. "All the..." includes people's personal projects >> (from scratch or patches to existing ones) that you will never see, >> future systems that come into existence long past your involvement in >> the project or even your lifetime, etc. > > Unless something has changed recently, Botan, Crypto++ and OpenSSL are > still being carried by most Linux distributions. OpenSSL is also > regularly distributed as part of other OSes, like AIX, Android, BSDs, > iOS, OS X and Solaris. > > And unlike some other projects,[1] Botan, Crypto++ and OpenSSL > actually work in practice on all the platforms without a configuration > program that performs feature tests. You are dead wrong on this topic. OpenSSL actually goes the other way and performs absolutely wacky tests like "are we running on big-endian amd64." Any cryptography library is going to have to perform feature tests (either at build time or run time) to determine whether features like hardware acceleration are possible. > [1] the Rust compiler comes to mind here. It works on Linux x86_64, > but it's hit or miss whether it works or not on other architectures > like ARMv7, Aarch64 and PowerPC, even after an approved configuration > program is run. Cargo is capable of doing build-time configuration tests. If a crate fails to properly run tests, it is not because the Rust ecosystem works as you believe it does. Ariadne ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-23 16:26 ` Ariadne Conill @ 2020-09-23 16:57 ` Jeffrey Walton 0 siblings, 0 replies; 23+ messages in thread From: Jeffrey Walton @ 2020-09-23 16:57 UTC (permalink / raw) To: musl On Wed, Sep 23, 2020 at 12:26 PM Ariadne Conill <ariadne@dereferenced.org> wrote: > > Hello, > > On 2020-09-23 10:16, Jeffrey Walton wrote: > > On Wed, Sep 23, 2020 at 12:08 PM Rich Felker <dalias@libc.org> wrote: > >> > >> On Wed, Sep 23, 2020 at 09:13:16AM -0400, James Y Knight wrote: > >>>> > >>>>> All I need to know is what version of Musl I am dealing with and I can > >>>>> configure myself. > >>>> > >>>> Are you willing to maintain an #ifdef forest for all the versions of > >>>> all the libcs and all the kernels your programs may be used with, so > >>>> you can list exhaustively the available features in every configuration? > >>> > >>> At the risk of jumping in on a question asked of someone else: yes, > >>> absolutely! (Not _all_ available features of course, just the ones > >>> required.) > >>> > >>> There are generally not that many nonstandard features you'd want to use in > >>> a typical program, and using an ifdef forest to implement an abstraction > >>> layer around those couple items is just fine. > >> > >> I can't know whether you're "willing", but you're definitely not > >> willing and able. "All the..." includes people's personal projects > >> (from scratch or patches to existing ones) that you will never see, > >> future systems that come into existence long past your involvement in > >> the project or even your lifetime, etc. > > > > Unless something has changed recently, Botan, Crypto++ and OpenSSL are > > still being carried by most Linux distributions. OpenSSL is also > > regularly distributed as part of other OSes, like AIX, Android, BSDs, > > iOS, OS X and Solaris. > > You are dead wrong on this topic. OpenSSL actually goes the other way > and performs absolutely wacky tests like "are we running on big-endian > amd64." Any cryptography library is going to have to perform feature > tests (either at build time or run time) to determine whether features > like hardware acceleration are possible. Sorry, my bad for the confusion. Botan, Crypto++ and OpenSSL do not perform Autoconf-like compile-time feature tests. Botan has a configure-like program, but it is used to select components. Preprocessor macros are used instead of feature tests. Crypto++ uses preprocessor macros. Preprocessor macros are used instead of feature tests. (This is slowly changing in Crypto++). OpenSSL uses a preconfigured profile. './Configure LIST' will list the profiles. It uses info from the profile and preprocessor macros are used instead of feature tests. Jeff ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-23 16:16 ` Jeffrey Walton 2020-09-23 16:26 ` Ariadne Conill @ 2020-09-23 16:36 ` Rich Felker 1 sibling, 0 replies; 23+ messages in thread From: Rich Felker @ 2020-09-23 16:36 UTC (permalink / raw) To: Jeffrey Walton; +Cc: musl On Wed, Sep 23, 2020 at 12:16:36PM -0400, Jeffrey Walton wrote: > On Wed, Sep 23, 2020 at 12:08 PM Rich Felker <dalias@libc.org> wrote: > > > > On Wed, Sep 23, 2020 at 09:13:16AM -0400, James Y Knight wrote: > > > > > > > > >All I need to know is what version of Musl I am dealing with and I can > > > > >configure myself. > > > > > > > > Are you willing to maintain an #ifdef forest for all the versions of > > > > all the libcs and all the kernels your programs may be used with, so > > > > you can list exhaustively the available features in every configuration? > > > > > > At the risk of jumping in on a question asked of someone else: yes, > > > absolutely! (Not _all_ available features of course, just the ones > > > required.) > > > > > > There are generally not that many nonstandard features you'd want to use in > > > a typical program, and using an ifdef forest to implement an abstraction > > > layer around those couple items is just fine. > > > > I can't know whether you're "willing", but you're definitely not > > willing and able. "All the..." includes people's personal projects > > (from scratch or patches to existing ones) that you will never see, > > future systems that come into existence long past your involvement in > > the project or even your lifetime, etc. > > Unless something has changed recently, Botan, Crypto++ and OpenSSL are > still being carried by most Linux distributions. OpenSSL is also > regularly distributed as part of other OSes, like AIX, Android, BSDs, > iOS, OS X and Solaris. > > And unlike some other projects,[1] Botan, Crypto++ and OpenSSL > actually work in practice on all the platforms without a configuration > program that performs feature tests. OpenSSL most certainly does not; it just has a fairly large set of known systems it works on. Early in musl history there were lots of problems with it; IIRC it wanted to use some broken ancient pty or termio APIs rather than the modern ones because __linux__ && !__GLIBC__, among other things. If you made up a new POSIX-conforming system from scratch and didn't teach OpenSSL about it, I'm almost sure it would have build or runtime problems. > [1] the Rust compiler comes to mind here. It works on Linux x86_64, > but it's hit or miss whether it works or not on other architectures > like ARMv7, Aarch64 and PowerPC, even after an approved configuration > program is run. I think now you're confusing host and target. Of course a compiler needs explicit support for each target arch/ABI, and this is not something detectable. This doesn't mean it can't run on arbitrary hosts. (Of course it's already unable to run on arbitrary hosts because it's written in Rust and thereby has a dependency on something that can't target arbitrary hosts, but you can hack around that with an emulator if you really care.) Rich ^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 2020-09-20 10:12 ` [musl] Re: OS detection wrong on Alpine Linux 3.10 Dmitry V. Levin 2020-09-20 11:19 ` Bruno Haible @ 2020-09-20 12:19 ` Ariadne Conill 1 sibling, 0 replies; 23+ messages in thread From: Ariadne Conill @ 2020-09-20 12:19 UTC (permalink / raw) To: musl, Dmitry V. Levin, Bruno Haible; +Cc: config-patches Hello, On 2020-09-20 04:12, Dmitry V. Levin wrote: > On Sat, Sep 19, 2020 at 03:30:54PM +0200, Bruno Haible wrote: >> The value of $host_os, determined by the current config.guess, is: >> - On Alpine Linux 3.9: linux-musl >> - On Alpine Linux 3.10: linux-gnu >> - On Alpine Linux 3.12: linux-musl >> >> The reason is that config.guess tests 'ldd --version'. However, in >> Alpine Linux 3.10, /usr/bin/ldd has been replaced with a shell script >> that does not understand the --version option: >> >> $ cat /usr/bin/ldd >> #!/bin/sh >> exec /lib/ld-musl-x86_64.so.1 --list -- "$@" >> $ /usr/bin/ldd --version 2>&1 >> /lib/ld-musl-x86_64.so.1: cannot load --version: No such file or directory >> >> Find attached a proposed fix. More details in >> <https://lists.gnu.org/archive/html/bug-gnulib/2020-09/msg00098.html>. >> >> Bruno > >> >From 6e8da56c68ad94175d67acfc6257e614fe74e01d Mon Sep 17 00:00:00 2001 >> From: Bruno Haible <bruno@clisp.org> >> Date: Sat, 19 Sep 2020 15:24:59 +0200 >> Subject: [PATCH] * config.guess: Fix determination of musl libc on Alpine >> Linux 3.10. >> >> --- >> ChangeLog | 5 +++++ >> config.guess | 14 ++++++-------- >> 2 files changed, 11 insertions(+), 8 deletions(-) >> >> diff --git a/ChangeLog b/ChangeLog >> index 4f106db..834f4e5 100644 >> --- a/ChangeLog >> +++ b/ChangeLog >> @@ -1,3 +1,8 @@ >> +2020-09-19 Bruno Haible <bruno@clisp.org> >> + >> + * config.guess: Don't use 'ldd --version' to determine the presence of >> + musl libc, as this fails on Alpine Linux 3.10. >> + >> 2020-09-08 Elad Lahav <e2lahav@gmail.com> >> Ben Elliston <bje@gnu.org> >> >> diff --git a/config.guess b/config.guess >> index 9aff91c..8d70ec2 100755 >> --- a/config.guess >> +++ b/config.guess >> @@ -2,7 +2,7 @@ >> # Attempt to guess a canonical system name. >> # Copyright 1992-2020 Free Software Foundation, Inc. >> >> -timestamp='2020-08-17' >> +timestamp='2020-09-19' >> >> # This file is free software; you can redistribute it and/or modify it >> # under the terms of the GNU General Public License as published by >> @@ -150,17 +150,15 @@ Linux|GNU|GNU/*) >> #elif defined(__dietlibc__) >> LIBC=dietlibc >> #else >> + #include <stdarg.h> >> + #ifdef __DEFINED_va_list >> + LIBC=musl >> + #else >> LIBC=gnu >> #endif >> + #endif >> EOF >> eval "`$CC_FOR_BUILD -E "$dummy.c" 2>/dev/null | grep '^LIBC' | sed 's, ,,g'`" >> - >> - # If ldd exists, use it to detect musl libc. >> - if command -v ldd >/dev/null && \ >> - ldd --version 2>&1 | grep -q ^musl >> - then >> - LIBC=musl >> - fi >> ;; >> esac >> > > Is this __DEFINED_va_list macro the official way of detecting musl? > It looks very fragile to me. There is no official way of detecting musl. Ariadne ^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2020-09-23 16:57 UTC | newest] Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <4768019.hHWyC0TzgU@omega> 2020-09-20 10:12 ` [musl] Re: OS detection wrong on Alpine Linux 3.10 Dmitry V. Levin 2020-09-20 11:19 ` Bruno Haible 2020-09-20 12:18 ` Ariadne Conill 2020-09-20 13:56 ` Szabolcs Nagy 2020-09-20 17:14 ` Rich Felker 2020-09-20 19:21 ` Bruno Haible 2020-09-20 20:58 ` Hadrien Lacour 2020-09-21 6:53 ` A. Wilcox 2020-09-21 11:46 ` Florian Weimer 2020-09-22 18:46 ` Rich Felker 2020-09-22 20:18 ` Bruno Haible 2020-09-22 20:33 ` Jeffrey Walton 2020-09-22 20:39 ` Jeffrey Walton 2020-09-22 21:04 ` Laurent Bercot 2020-09-22 21:17 ` Jeffrey Walton 2020-09-23 8:49 ` Laurent Bercot 2020-09-23 13:13 ` James Y Knight 2020-09-23 16:08 ` Rich Felker 2020-09-23 16:16 ` Jeffrey Walton 2020-09-23 16:26 ` Ariadne Conill 2020-09-23 16:57 ` Jeffrey Walton 2020-09-23 16:36 ` Rich Felker 2020-09-20 12:19 ` Ariadne Conill
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).