[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250209144612.GZ10433@brightrain.aerifal.cx>
Date: Sun, 9 Feb 2025 09:46:13 -0500
From: Rich Felker <dalias@...c.org>
To: Filipe Laíns <lains@...eup.net>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] confstr: add support for _CS_GNU_LIBC_VERSION
On Fri, Jan 31, 2025 at 01:27:37AM +0000, Filipe Laíns wrote:
> This provides a way to detect at runtime if musl is the libc implementation,
> and to check its version.
>
> This functionality is useful when introspecting the system, to determine
> binary compatibility of on packaging applications. An example use-case
> can be demonstrated by Python PEP 656 [1], whose implementation
> currently require spawning a new process and parsing the output of
> ld.so to detect the musl version.
>
> [1] https://peps.python.org/pep-0656/
>
> Signed-off-by: Filipe Laíns <lains@...eup.net>
> ---
> WHATSNEW | 1 +
> src/conf/confstr.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/WHATSNEW b/WHATSNEW
> index 7bd90728..e7e50d2f 100644
> --- a/WHATSNEW
> +++ b/WHATSNEW
> @@ -2417,6 +2417,7 @@ compatibility:
> - string.h no longer provides (C23-incompat) non-prototype decl of basename
> - fstatat statx backend now matches stat syscall non-automounting behavior
> - mntent interfaces now handle escaped whitespace in paths/options
> +- confstr now supports _CS_GNU_LIBC_VERSION
>
> standards updates:
> - printf %lc of nul wchar now produces output
> diff --git a/src/conf/confstr.c b/src/conf/confstr.c
> index 3d417284..a9ac87f4 100644
> --- a/src/conf/confstr.c
> +++ b/src/conf/confstr.c
> @@ -1,12 +1,15 @@
> #include <unistd.h>
> #include <stdio.h>
> #include <errno.h>
> +#include "version.h"
>
> size_t confstr(int name, char *buf, size_t len)
> {
> const char *s = "";
> if (!name) {
> s = "/bin:/usr/bin";
> + } else if (name == _CS_GNU_LIBC_VERSION) {
> + s = "musl " VERSION;
> } else if ((name&~4U)!=1 && name-_CS_POSIX_V6_ILP32_OFF32_CFLAGS>35U) {
> errno = EINVAL;
> return 0;
> --
> 2.48.1
As discussed on IRC, I fail to see any way this admits doing something
beneficial, and it admits doing lots of things that are decidedly
non-beneficial, like using hard-coded knowledge about versions as a
proxy for something else you want to test. Basically the same
rationale as why we don't have __MUSL__.
Moreover, in the package manager setting you describe, a runtime test
on the host is really not what's wanted. It assumes the host you're
running the package manager on is the same as the target it's
installing packages for. For thing kind of purpose, even if you did
deem it reasonable to hard-code characteristics of particular version
strings, you'd want not an introspective test but a tool for examining
a target libc.so from outside to determine its version. The more
reasonable thing, of course, would be doing something like nm -D to
probe for the particular interfaces you want to ensure are present.
Can you provide any more insights into what the desired behavior
should be when the package to be installed isn't compatible with
version of musl present? What are the intended benefits of being able
to reject it at install time rather than just installing and getting a
runtime error the user can deal with by upgrading? Are you trying to
facilitate holding back to older versions of a package if the newer
version was built with newer musl as a linkage dependency? Maybe we
can figure out ways that are acceptable to make this work more like
what you want, but at this point I'm unclear on what the intended UX
and rationale behind it are.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
