[foreign] jextract issue with system headers
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Wed May 1 10:39:51 UTC 2019
Hi,
I was trying to rerun some examples I had with the new generation
scheme. One of them has failed - it is a simple getpid test, that is, an
extraction of the 'unistd.h' file:
$ jextract -t stdlib -d classes /usr/include/unistd.h
java.lang.RuntimeException: In memory compilation failed:
/stdlib/x86_64_linux_gnu/bits/confname_h.java:2451: error: method
_PC_LINK_MAX() is already defined in interface confname_h
public int _PC_LINK_MAX();
^
/stdlib/x86_64_linux_gnu/bits/confname_h.java:2459: error: method
_PC_MAX_CANON() is already defined in interface confname_h
public int _PC_MAX_CANON();
^
/stdlib/x86_64_linux_gnu/bits/confname_h.java:2467: error: method
_PC_MAX_INPUT() is already defined in interface confname_h
public int _PC_MAX_INPUT();
The output goes on with 300 errors.
Turns out that jextract is generating duplicate constants, one coming
from the enum constant and one coming from a #define with same name -
the pattern in the header is as follows:
/* Values for the NAME argument to `pathconf' and `fpathconf'. */
enum
{
_PC_LINK_MAX,
#define _PC_LINK_MAX _PC_LINK_MAX
_PC_MAX_CANON,
#define _PC_MAX_CANON _PC_MAX_CANON
_PC_MAX_INPUT,
...
}
Should jextract check for duplicates before emitting a constant with
same name? Or should we use some kind of mangling to distinguish between
the #defined constants and the enum ones? I think I'd rather see the
former in the short term.
Maurizio
More information about the panama-dev
mailing list