This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Specific Linux syscalls for glibc API
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 18 Nov 2015 15:06:00 +0000
- Subject: Re: Specific Linux syscalls for glibc API
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511171606330 dot 14808 at digraph dot polyomino dot org dot uk> <564C4DCA dot 3010607 at redhat dot com> <alpine dot DEB dot 2 dot 10 dot 1511181321270 dot 30047 at digraph dot polyomino dot org dot uk> <564C8CE6 dot 9000003 at redhat dot com>
On Wed, 18 Nov 2015, Pedro Alves wrote:
> In general, I wonder whether helping the cross-compilation use case (of
> portable programs, not of glibc itself) should be considered in
> determining the guidelines of what/when to wrap and provide in the glibc
> API (not getrandom in particular, but in general). That is, if some
> entry point is always provided in the glibc API that may or may not fail
> with ENOSYS depending on port, then compile/link autoconf-style checks
> are no longer sufficient to determine whether a function is available,
> while run-time checks obviously don't work when cross compiling.
>
> Is it already the case that functions in the glibc API may be exported
> on all ports but then fail with ENOSYS on some?
If a function is a pure stub, then gnu/stubs.h will indicate this and
autoconf knows about that. If it may or may not fail at runtime depending
on kernel support, then, yes, applications need to check at runtime
themselves.
--
Joseph S. Myers
joseph@codesourcery.com