mailing list of musl libc
 help / color / mirror / Atom feed
* [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 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

* 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: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-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

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

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ http://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git