Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 May 2020 19:31:38 +0300
From: Alexander Scherbatiy <>
To: Rich Felker <>
Subject: Re: musl libc version

On 27.05.2020 18:57, Rich Felker wrote:

> On Wed, May 27, 2020 at 06:44:38PM +0300, Alexander Scherbatiy wrote:
>> Hello,
>> Using glibc it is possible to get GNU C library version using
>> confstr() function and _CS_GNU_LIBC_VERSION constant.
>> In musl the confstr() returns EINVAL for _CS_GNU_LIBC_VERSION.
>> Is there a way to get libc version in musl?
> Can you describe what you're trying to achieve with a version number?
  It is used mostly for logging purposes.
  For example the JVM crash dump [1] prints libc version as "unknown 
  This is because the confstr is used in os_linux.cpp [2]

   It would be nice to know from a crash dump was JDK linked with glibc 
or musl in Alpine Linux and which version of musl has been used.



> musl specifically doesn't publish version numbers via macros or
> runtime interfaces because they're a poor proxy for checking for the
> particular feature/property/whatever you care about. For instance,
> distros may backport the thing you want to an older version, and even
> if not, you end up hard-coding knowledge about particular libcs that
> quickly bitrots rather than making something robust and future-proof.
> With that said, ability to test for some things is presently
> inadequate, and there's a proposal I've made (based on previous
> discussions with others) on libc-coord to improve this in a cross-libc
> manner:
> If you have input into what kinds of things you need to be able to
> test for it would be very helpful.
> 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.