mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] musl libc version
@ 2020-05-27 15:44 Alexander Scherbatiy
  2020-05-27 15:57 ` Rich Felker
  0 siblings, 1 reply; 4+ messages in thread
From: Alexander Scherbatiy @ 2020-05-27 15:44 UTC (permalink / raw)
  To: musl

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?

Thanks,
Alexander.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] musl libc version
  2020-05-27 15:44 [musl] musl libc version Alexander Scherbatiy
@ 2020-05-27 15:57 ` Rich Felker
  2020-05-27 16:31   ` Alexander Scherbatiy
  2020-05-27 18:28   ` Dmitry Samersoff
  0 siblings, 2 replies; 4+ messages in thread
From: Rich Felker @ 2020-05-27 15:57 UTC (permalink / raw)
  To: Alexander Scherbatiy; +Cc: musl

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

https://www.openwall.com/lists/libc-coord/2020/04/22/1

If you have input into what kinds of things you need to be able to
test for it would be very helpful.

Rich

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] musl libc version
  2020-05-27 15:57 ` Rich Felker
@ 2020-05-27 16:31   ` Alexander Scherbatiy
  2020-05-27 18:28   ` Dmitry Samersoff
  1 sibling, 0 replies; 4+ messages in thread
From: Alexander Scherbatiy @ 2020-05-27 16:31 UTC (permalink / raw)
  To: Rich Felker; +Cc: musl

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 
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.

[1] https://bugs.openjdk.java.net/secure/attachment/87289/hs_err_pid5502.log
[2] 
https://hg.openjdk.java.net/portola/portola/file/7ff60204a181/src/hotspot/os/linux/os_linux.cpp#l607

  Thanks,
  Alexander.

> 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:
>
> https://www.openwall.com/lists/libc-coord/2020/04/22/1
>
> If you have input into what kinds of things you need to be able to
> test for it would be very helpful.
>
> Rich

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [musl] musl libc version
  2020-05-27 15:57 ` Rich Felker
  2020-05-27 16:31   ` Alexander Scherbatiy
@ 2020-05-27 18:28   ` Dmitry Samersoff
  1 sibling, 0 replies; 4+ messages in thread
From: Dmitry Samersoff @ 2020-05-27 18:28 UTC (permalink / raw)
  To: musl, Rich Felker, Alexander Scherbatiy

Hello Rich,

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

I like your proposal, but I'm in doubt that it's possible to coordinate 
it across all involved parties.

Absence of musl/libc-version.h (similar to gnu/*) and corresponding api 
creates a burden for support folks (as Alexander already mentioned) and 
people maintaining cross platform software like JVM.

 > If you have input into what kinds of things you need to be able to
 > test for it would be very helpful.

*For example*, on another topic we discussed a difference in behavior of 
dlopen() between glibc and musl. if sometimes musl will change its 
behavior, workaround code in java launcher could be deprecated and 
placed under if musl_version() < ...

*Another example is less technical but more effort driven*, absence of 
dlvsym() in musl leads to significant changes in libnuma handling code 
in JVM.
   Numa support have big performance impact and all related changes have 
to be carefully tested in a different environment.
   So I would prefer to put these changes under if musl() (or ever 
#ifdef MUSL) rather than test for dlvsym() presence at runtime. It 
allows me to be sure that we are always on the known and tested scenario.

-Dmitry

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?
> 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:
> 
> https://www.openwall.com/lists/libc-coord/2020/04/22/1
> 
> If you have input into what kinds of things you need to be able to
> test for it would be very helpful.
> 
> Rich
> 


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-05-27 18:29 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-27 15:44 [musl] musl libc version Alexander Scherbatiy
2020-05-27 15:57 ` Rich Felker
2020-05-27 16:31   ` Alexander Scherbatiy
2020-05-27 18:28   ` Dmitry Samersoff

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).