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=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 2096 invoked from network); 20 Sep 2020 13:56:43 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2020 13:56:43 -0000 Received: (qmail 9677 invoked by uid 550); 20 Sep 2020 13:56:41 -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 9659 invoked from network); 20 Sep 2020 13:56:41 -0000 Date: Sun, 20 Sep 2020 15:56:29 +0200 From: Szabolcs Nagy To: Bruno Haible Cc: "Dmitry V. Levin" , config-patches@gnu.org, musl@lists.openwall.com Message-ID: <20200920135629.GI2947641@port70.net> Mail-Followup-To: Bruno Haible , "Dmitry V. Levin" , config-patches@gnu.org, musl@lists.openwall.com References: <4768019.hHWyC0TzgU@omega> <20200920101249.GA29409@altlinux.org> <1721942.iyVTE8TspN@omega> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1721942.iyVTE8TspN@omega> Subject: Re: [musl] Re: OS detection wrong on Alpine Linux 3.10 * Bruno Haible [2020-09-20 13:19:13 +0200]: > Dmitry V. Levin wrote: > > Is this __DEFINED_va_list macro the official way of detecting musl? > > No, but in a world where the musl people don't want to provide an official > way [1][2] and the Alpine Linux people break their previously working way of > detecting musl [3], we (GNU) need to use our own heuristics to fulfil the > practical need of programs (especially test suites) to distinguish musl > systems from glibc systems. we have not seen a "practical need of programs to distinguish musl systems from glibc systems". instead we have seen a practical need to detect specific c runtime behaviours and extensions. even in the glibc world using __GLIBC__ to detect features is not reliable since there are heavily patched glibcs out there. (though the way glibc handles api and abi stability means it mostly works, but this is unreasonable to expect across different implementations)