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: Andreas Schwab <schwab at suse dot de>
- To: Pedro Alves <palves at redhat dot com>
- Cc: Joseph Myers <joseph at codesourcery dot com>, Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 18 Nov 2015 15:56:38 +0100
- 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>
Pedro Alves <palves@redhat.com> writes:
> 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.
AC_CHECK_FUNC considers stub functions in glibc as non-existent. In any
case, whether a function exists in glibc has never been a guarantee that
the running kernel actually provides the necessary syscall.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."