[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