[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 07 Jul 2023 11:20:26 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: __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’re cross compiling and the thing you’re interested in is *runtime* behaviour, so configure-style checks simply aren’t an option. In a cross-compilation situation the only thing they can test is that a program will *build*; they can’t test its behaviour since you don’t 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
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
