From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20458 invoked from network); 27 May 2020 16:31:54 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 16:31:54 -0000 Received: (qmail 27686 invoked by uid 550); 27 May 2020 16:31:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27659 invoked from network); 27 May 2020 16:31:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell-sw-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=r1HR5t24W9EVrUwYNqJGT0cs+APUUuhSuWz7puoToD0=; b=sxt5fT22X49tDZCWxBBcqr8CMdubq1mXC0OQUdhwTyDVxPd0f8uk6htny2tgvq7QlA JOaYDnl1jHcnK9nxA4TkC9/14EO1jRKizn5x8e8gORyIy3R0kDpWatAuLCftNmEIpA+P xWQYrCBXoDWoCDYSX0u8E/sJZL9SyRPn0xtgTUy4xiTnUeMh/4XOxDyLCX5hLqhF7XZm 5kK0g/Tpd2GQhwZOU4gWfvh+YJPQsynusXXpcinv9OK4LjBYJ6FAH0k2u4Aqh5Yi6yry 4el1F6N0faes6rwghAmw1TL82bVcLUsNVGQszrDZps7lASj80RBtmyCrXW+wZWCg9Lhn Q0iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=r1HR5t24W9EVrUwYNqJGT0cs+APUUuhSuWz7puoToD0=; b=apKDQzIwXeGlgVrcKOvqlIX/oVKSyy/MhU67Y5z/pTNBgNLFNNgQa9ccGuKDDnaajf zJsYOZsLkZ3cwMMdff1DIaavMaWkvrVDrsFgv6OXxwwr52tytnQzh+03kgF3/qxFRPZc qqihqmUcjs3TIgCVre1Ff17N3ISzBRq7iO6xWXrJbmL04hyol5aF0coVrkpc4yqHGGMA 2opKLzTUxFvwC9D9fW+vkEYTmUv8wCOBPX75q716xnK8cc04SlXwBirepbWI9Mc/VWzP EBPc6SS6xBp4h1JP1nOxIgmJZVyR9gEB2Lm8WtqC8l4EyOysrImGN0rAnfIyHd7VWlAa CnNw== X-Gm-Message-State: AOAM532QEh9hEJk1MhTkXKaWtXA19+qoQqrDNkazwSJ69ujjzvV+4Nqw 19kOUZ0zj05twCR3hh0fEIkAG9Jmbec= X-Google-Smtp-Source: ABdhPJx4vLtD7n7qd9832amLsZMdc2rRBca8UjIuaTdc8RsS/M8OMNtJx55rQLbUPepujmF1A2ISew== X-Received: by 2002:ac2:5df2:: with SMTP id z18mr3507655lfq.151.1590597099907; Wed, 27 May 2020 09:31:39 -0700 (PDT) To: Rich Felker Cc: musl@lists.openwall.com References: <2059d75f-0428-d41e-444b-17365eef71bf@bell-sw.com> <20200527155735.GU1079@brightrain.aerifal.cx> From: Alexander Scherbatiy Message-ID: <51927e73-f02d-4cbb-13b1-65ac86c18ade@bell-sw.com> Date: Wed, 27 May 2020 19:31:38 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200527155735.GU1079@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [musl] 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 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