jextract unable to find limits.h from limits.h

[Jorn Vernee]

The missing clang headers could be due to a mis-configuration of the 
build, be sure that with --with-libclang-include-aux points to the 
$LLVM_ROOT/lib/clang/<version>/include direcoty. You can check if this 
is already the case by looking at the `CLANG_INCLUDE_AUX_PATH` variable 
in the build/<config>/spec.gmk file.

The build has been tested to work with the pre-built LLVM bundles at: 
http://releases.llvm.org/download.html So it would be simplest to 
install one of those and point the --with-libclang configuration option 
at the root of the install. I've also tested with a clang distro built 
from sources. The key is the particular directory structure.

The error you are seeing looks like the error caused by a behavioral 
change of one of the libclang APIs in LLVM 8+. For now, only LLVM 
version 7 is supported (but there is 
https://bugs.openjdk.java.net/browse/JDK-8234237 for updating to 9).

Jorn

On 18/11/2019 18:22, Ty Young wrote:
>
> 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?
>>>