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: Pedro Alves <palves at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 18 Nov 2015 15:18:40 +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> <alpine dot DEB dot 2 dot 10 dot 1511181503290 dot 17828 at digraph dot polyomino dot org dot uk>
On 11/18/2015 03:06 PM, Joseph Myers wrote:
> 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.
Ah, I had never noticed the gnu/stubs.h mechanism before. Thanks.
--
Pedro Alves