[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260411173821.GW1827@brightrain.aerifal.cx>
Date: Sat, 11 Apr 2026 13:38:22 -0400
From: Rich Felker <dalias@...c.org>
To: Gilles Peskine <gilles.peskine@....com>
Cc: musl@...ts.openwall.com
Subject: Re: Detecting getrandom() or syscall()
On Sat, Apr 11, 2026 at 06:03:14PM +0200, Gilles Peskine wrote:
> Thanks for the reply!
>
> On 11/04/2026 03:54, Rich Felker wrote:
> > The historical and current way this is recommended to be done is with
> > compile and link tests at build time. This can be done with autoconf,
> > or on your own with a build rule (e.g. in a makefile) that executes
> > the compile or link attempt command and generates a header fragment
> > from the exit status. I imagine cmake and other build systems some
> > folks prefer nowadays have similar facilities.
> That is the historical way, yes, but mostly to cope with the lack of
> standardization of 1980s Unix systems. Compile-and-run isn't doable
> anyway on embedded systems where one is usually cross-compiling.
Compile-and-run is always-wrong, as you say, because it's not
compatible with cross-compiling. That's why you do compile-only
(checking for a header, type, etc.) or compile-and-link (checking for
a function).
> I've found that compile-only isn't reliable anyway in this specific
> case (with some other libc, syscall() was declared, but was not
> available at link time). Compile-and-link might work on Linux, but
> even there I'm not sure. It certainly doesn't work on embedded systems
> where one links a single code image, and our build scripts don't know
> how to link a whole system image. In any case, I don't think we will
> ever have enough developer time to maintain a compile-and-link platform
> discovery tool for a small subset of our users.
A link test is not supposed to be attempting to link your whole system
image. It's supposed to be attempting to link whatever the minimal
unit possible to check for the symbol resolving successfully would be.
Normally that's just $(CC) -o /dev/null testcase.c, possibly with
$(CFLAGS), $(LDFLAGS), and $(LIBS) or equivalent included if
appropriate for your build setup (like if the symbol is expected to be
in a nondefault library).
> > There is a proposal I put forth on the libc-coord mailing list in
> > 2020, titled "Macro-based advertisement of libc extensions", for
> > implementors to agree on a naming convention for macros that would
> > declare the presence of nonstandardized but common interfaces and
> > features, so that you could use preprocessor conditionals on these
> > directly without having to run your own tests, and so you could know
> > the availability of untestable things (things where any test would
> > produce undefined behavior).
>
> I agree that something like
> #if __has_function_syscall
> is the way to go! So what macro can we use to test for the presence of
> syscall() on musl or elsewhere?
Eventually having something like this that's not musl-specific but
that glibc, BSD folks, etc. agree on the naming for is my goal here.
But for now, autoconf style tests are what you have. They DO work
(except for things that are untestable because the test would be UB),
and are not subject to the problems you seem to be concerned they
might have.
Rich
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.
