[foreign] road to posix

[Florian Weimer]

On 05/29/2018 04:51 PM, Maurizio Cimadamore wrote:
> My bad - it looks like jextract has some basic support for constants 
> like the ones defined in limits.h.
> 
> However, some manual hackery is required, since such constants are not 
> defined when using a recent GCC compiler.
> 
> But I've been able to get at the constants by passing the following flag 
> to jextract:
> 
> -C-U__GNUC__
> 
> (that is, undefine __GNUC__, which will force definition of the 
> constants in limit.h)

That's really odd.  In general, it's a mistake to define __GNUC__ when 
you are not.  We occasionally have problems with third-party vendor 
compilers that do this (Clang is generally more well-behaved).

Anyway, is this really the direction to take?  I expect there will be at 
least some overlap with providing headers suitable for use with C++ 
modules, which means that it's necessary or at least very desirable to 
wean the headers off preprocessor symbols used by applications.

At least for core libraries, we might end up having to provide curated 
headers which are more easily consumed in this way.

There is also the issue that headers just aren't enough.  On GNU, you 
also need at the DSOs at the time you extract ABI artifacts from headers 
and capture symbol versions.  If you don't do that, applications *will* 
stop working once a new symbol version is introduced.  There is some 
debate whether the symbol information should be located in the header 
file as well.

Anyway, what I'm really trying to say is that before you go to heroics 
to consume unchanged glibc headers, please come to libc-alpha and ask us 
to provide something that is digested more easily.  They are other 
potential consumers as well (C++ modules I mentioned, but LuaJIT might 
benefit as well).

Thanks,
Florian