jextract unable to find limits.h from limits.h

[Ty Young]

On 11/18/19 4:43 AM, Jorn Vernee wrote:
> Hi Ty,
>
> Note that it's using # include_next <limits.h> there, in other words 
> it's trying to find the next limits.h file on the include path, and 
> presumably throwing an error because there is none.
>
> What I'm confused about is that it should be picking up the clang 
> header that is bundled with jextract instead, which just does:
>
> /* The system's limits.h may, in turn, try to #include_next GCC's 
> limits.h.
>    Avert this #include_next madness. */
> #if defined __GNUC__ && !defined _GCC_LIMITS_H_
> #define _GCC_LIMITS_H_
> #endif
>
> If I do a similar jextract run (albeit on Windows) with the latest 
> snapshot I don't get the same error :/
>
> You could:
> 1.) Add `--log INFO` to the command and check whether the 
> $JDK/conf/jextract directory is being included
> 2.) Check whether that directory actually exists and contains a bunch 
> of header files.


Right, so after looking into conf/jextract it looks like if you build a 
Panama JDK from source yourself the Clang headers aren't included for 
some reason. How do you include the headers with the build?


...However after copying the headers from the EA build into the custom 
compiled version it still fails:


WARNING: Some library names could not be resolved
WARNING: can not compute layout for type Type{ spelling=struct 
libusb_bos_dev_capability_descriptor, kind=Record } with flexible array 
member. Emitting undefined layout reference.
WARNING: can not compute layout for type Type{ spelling=struct 
libusb_bos_descriptor, kind=Record } with flexible array member. 
Emitting undefined layout reference.
WARNING: can not compute layout for type Type{ spelling=struct 
libusb_transfer, kind=Record } with flexible array member. Emitting 
undefined layout reference.
Ignoring duplicate symbol: ITIMER_REAL
Ignoring duplicate symbol: ITIMER_VIRTUAL
Ignoring duplicate symbol: ITIMER_PROF
Cannot write source file org.linux.libusb.bits.thread_shared_types_h, 
cause: jdk.internal.clang.TypeLayoutError: InvalidFieldName. type: Type{ 
spelling=struct __pthread_cond_s, kind=Record }, fieldName: __low
Tree causing above exception is: __pthread_cond_s
   ------------------------
   Cursor: __pthread_cond_s
   Kind: StructDecl
   Location: /usr/include/bits/thread-shared-types.h at 171:8
   Is system header? true
   Is from main file? false
   == Type ==
   Type: struct __pthread_cond_s
   Type Kind: Record
   Declared by cursor: __pthread_cond_s of kind StructDecl
   Location: /usr/include/bits/thread-shared-types.h at 171:8
   Is system header? true
   Is from main file? false
   Declaring cursor is definition? true
   Size: 48 bytes
   Is this cursor definition? true

Exception in thread "main" java.lang.RuntimeException: In memory 
compilation failed: /org/linux/libusb/bits/pthreadtypes_h.java:424: 
error: cannot find symbol
         public 
org.linux.libusb.bits.thread_shared_types_h.__pthread_cond_s __data$get();
                                                           ^
   symbol:   class __pthread_cond_s
   location: interface thread_shared_types_h
/org/linux/libusb/bits/pthreadtypes_h.java:427: error: cannot find symbol
         public void 
__data$set(org.linux.libusb.bits.thread_shared_types_h.__pthread_cond_s 
value);
^
   symbol:   class __pthread_cond_s
   location: interface thread_shared_types_h
/org/linux/libusb/bits/pthreadtypes_h.java:430: error: cannot find symbol
         public 
java.foreign.memory.Pointer<org.linux.libusb.bits.thread_shared_types_h.__pthread_cond_s> 
__data$ptr();
^
   symbol:   class __pthread_cond_s
   location: interface thread_shared_types_h
3 errors

     at 
jdk.jextract/com.sun.tools.jextract.InMemoryJavaCompiler.compile(InMemoryJavaCompiler.java:59)
     at 
jdk.jextract/com.sun.tools.jextract.Writer.ensureSourcesCompiled(Writer.java:49)
     at jdk.jextract/com.sun.tools.jextract.Writer.writeJar(Writer.java:115)
     at jdk.jextract/com.sun.tools.jextract.Main.runInternal(Main.java:342)
     at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:211)
     at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:352)



>
> Jorn
>
> On 18/11/2019 03:04, Ty Young wrote:
>> Hi,
>>
>>
>> I tried generating bindings for libusb using:
>>
>>
>> jextract -t org.linux.libusb -L /usr/lib -llibusb-1.0 
>> --record-library-path /usr/include/libusb-1.0/libusb.h -o 
>> org.linux.libusb
>>
>>
>> but am met with:
>>
>>
>> java.lang.RuntimeException: /usr/include/limits.h:124:16: fatal 
>> error: 'limits.h' file not found
>>
>>
>> Which is odd: jextract can't find the file causing the error while 
>> reading from the file it's throwing an error about.
>>
>>
>> This is the line's code + comment:
>>
>>
>>  /* Get the compiler's limits.h, which defines almost all the ISO 
>> constants.
>>
>>     We put this #include_next outside the double inclusion check because
>>     it should be possible to include this file more than once and 
>> still get
>>     the definitions from gcc's header.  */
>> #if defined __GNUC__ && !defined _GCC_LIMITS_H_
>> /* `_GCC_LIMITS_H_' is what GCC's file defines.  */
>> # include_next <limits.h>
>> #endif
>>
>>
>> Is this a jextract bug or am I doing something wrong?
>>