jextract unable to find limits.h from limits.h

[Ty Young]

On 11/18/19 2:14 PM, Jorn Vernee wrote:
> 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.


Alright, thank you.


>
> 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).


To be clear, if v9 headers are specified when compiling from source will 
this fix the errors or will a change in the JDK source itself be required?


>
> 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?
>>>>