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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 702 invoked from network); 27 May 2020 18:29:15 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 18:29:15 -0000 Received: (qmail 3940 invoked by uid 550); 27 May 2020 18:29:13 -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 3913 invoked from network); 27 May 2020 18:29:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samersoff.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:References:To:Subject:From:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=l+BxupbXdBikAJIV7FCBIySsY8fVIl6dIuz6UU3IY9g=; b=UgdOUS6T+uQsZUlNZNkbyt8y10 g5ZbI3p4wrJkO/I5t4du03GEmBgRb9lCwi9cx7PhN/42v1+JTGOkP8GQ9EMQaSZ8WI9EFTaD86RAm a9yQdIEkvIsywf+O6XNeQUwMxzuiEp4NwGU946OniJDro6wbykPdYW1ZWzZY/VUj1Bi4=; From: Dmitry Samersoff To: musl@lists.openwall.com, Rich Felker , Alexander Scherbatiy References: <2059d75f-0428-d41e-444b-17365eef71bf@bell-sw.com> <20200527155735.GU1079@brightrain.aerifal.cx> Message-ID: Date: Wed, 27 May 2020 21:28:49 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <20200527155735.GU1079@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Authenticated-As: dms X-SpamProbe: GOOD 0.0000034 0b3ea46e4c0f8e6128199b2325422888 Subject: Re: [musl] musl libc version 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 >