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,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15045 invoked from network); 7 Jul 2023 11:20:42 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Jul 2023 11:20:42 -0000 Received: (qmail 5649 invoked by uid 550); 7 Jul 2023 11:20:38 -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 5613 invoked from network); 7 Jul 2023 11:20:38 -0000 From: "Laurent Bercot" To: musl@lists.openwall.com Date: Fri, 07 Jul 2023 11:20:26 +0000 Message-Id: In-Reply-To: References: <309EDCC9-2402-46B5-BDBD-B96677E470DD@apple.com> <168864586814.64499.13397704850676744237@alexps.local> User-Agent: eM_Client/9.2.1735.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] __MUSL__ macro I am agnostic on the whole __MUSL__ thing (I can see the validity of arguments on both sides) but, as a C developer often brawling with the following issue, I have Opinions: >1. You=E2=80=99re cross compiling and the thing you=E2=80=99re interested= in is *runtime* behaviour, so configure-style checks simply aren=E2=80=99t= an option. In a cross-compilation situation the only thing they can test i= s that a program will *build*; they can=E2=80=99t test its behaviour since= you don=E2=80=99t necessarily have anywhere to run it. This happens a lot, because there are a lot of subtly different behaviours that can only be tested at run-time, and it's pretty annoying indeed. The thing is, a __MUSL__ macro would not help in that case, unless you're willing to go the extra mile and perform a herculean task (you're probably not). I don't want to remember, store, and include in every package I=20 publish, a set of "right combination of feature test macros -> behaviour" mappings. This is extremely cumbersome to use; best case, it ends up in a giant header file with #ifdef forests, worst case, it gets desynced across projects and becomes yet another source of headaches. Even GNU autoconf, the absolute reference in configuration bloatware, does not do this. It includes an extensive set of build-time tests and of run-time tests that work on native builds, but it does not store predetermined run-time test values for cross-builds. Instead, on cross-builds, autoconf *assumes* behaviours (and, obviously, gets them wrong half the time). The only way to make it viable is if there were some organization that collected, gathered and published such a dataset on a well-known site in an easy-to-use format for every build system out there (and dear reader, if you reflexively thought "JSON", you lost, close your mail client and try again later). That is tremendous work, that can only be achieved via benevolent funding and/or extensive community cooperation. And then you'd have to convince all the build systems to use it. Given the state of open source in 2023, I'm not holding my breath. The usual counter-argument to this proposition is "but having something is better than nothing", and it is also wrong. We already have a lot of somethings that should be better than nothing; but apparently, they all suck, since people cannot stop inventing new somethings that will, too, doubtlessly be better than nothing. This problem needs to be solved for everyone once and for all; a new partial solution would only add to the pile of reinvented square wheels. (The good thing about square wheels is that they stack nicely.) In short, __MUSL__ would not help with run-time tests in cross-builds, because 1. nobody would use it, 2. the people who would use it would use it wrong, 3. the people who use it right would be overwhelmed by the amount of boilerplate and maintenance this requires, 4. solving the boilerplate/maintenance thing basically starts with abolishing capitalism and we're not going to discuss that here. -- Laurent