[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 7 Jul 2023 07:45:28 -0400
From: Jeffrey Walton <noloader@...il.com>
To: musl@...ts.openwall.com
Subject: Re: __MUSL__ macro
On Fri, Jul 7, 2023 at 3:14 AM Alastair Houghton <ahoughton@...le.com> wrote:
>
> On 6 Jul 2023, at 13:17, Alex Xu <alex_y_xu@...oo.ca> wrote:
> > [...]
> > Configure-time checks for specific functionality are a standard part of
> > writing portable C code. Preprocessor checks for specific platforms lead
> > to ifdef swamps that are still not portable to any platforms not
> > initially considered.
>
> There are two situations where the lack of macros is absolutely a problem and there isn’t a sane workaround.
>
> 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.
>
> 2. You’re in a header-only library, particularly one where the final environment you’re running in wasn’t available at whatever configuration time you had, assuming you had one at all. A really good example of this is the built-in headers in Clang or GCC, but the problem also applies to things like STL or Boost.
A third problem is, Musl assumes a project is using Autotools or
similar. That's not always the case.
We use preprocessor signalling to enable or disable code paths at build time.
(In fact, we do not wish Autotools on our worst enemies.)
Jeff
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.
