Jextract tool-provider bug?

[Maurizio Cimadamore]

On 12/08/2019 20:34, Mark Hammons wrote:
> Here's the output:
>
> issuing command jextract /usr/include/wlr/types/wlr_output.h 
> /usr/include/wlr/backend.h /usr/include/wlr/render/wlr_renderer.h 
> --package-map /usr/include/wlr/backend=wlroots.backend_headers 
> --package-map /usr/include/bits/types=usr.include.bits.type_headers -I 
> /usr/include/wlr -I /usr/include/wayland -I /usr/include/pixman-1 -C 
> -DWLR_USE_UNSTABLE -L /usr/lib64 --record-library-path -l wlroots -t 
> wlroots -o 
> /home/mhammons/Documents/MyProjects/Skylight/javahelp/lib/wlroots.jar
>
And, you said, issuing this command from command line works?

Have you tried issuing with ToolProvider API from Java?

Maurizio

> ~Mark
>
> On 8/12/19 1:10 PM, Mark Hammons wrote:
>>
>> I will get you a copy tonight when I return home. All I can say right 
>> now is that the output jextract command worked when entered into a 
>> terminal on its own.
>>
>> ~Mark
>>
>> On 12/08/2019 12:37, Maurizio Cimadamore wrote:
>>>
>>> It would also be helpful to get the output of this statement:
>>>
>>> logger.info(s"issuing command jextract ${command.mkString(" ")}")
>>>
>>> Maurizio
>>>
>>> On 12/08/2019 11:30, Mark Hammons wrote:
>>>>
>>>> https://github.com/markehammons/Skylight/blob/DottyRebuild/build.sc
>>>>
>>>>
>>>> The jextract method and run tool method in that file are how I’m 
>>>> invoking it. When I invoke from Sbt (finally learned how to 
>>>> override its scala version with one that works with jdk14+), the 
>>>> Sbt version of the code works, so maybe this is something related 
>>>> to the way mill launches tasks.
>>>>
>>>>
>>>> Mark Edgar Hammons II - Ingénieur d'études at BioEmergences
>>>> 0603695656
>>>>
>>>> On 11 Aug 2019, at 23:46, Maurizio Cimadamore 
>>>> <maurizio.cimadamore at oracle.com 
>>>> <mailto:maurizio.cimadamore at oracle.com>> wrote:
>>>>
>>>>> So, jextract works but the tool provider does not?
>>>>>
>>>>> How are you invoking jextract exactly?
>>>>>
>>>>> Thanks
>>>>> Maurizio
>>>>>
>>>>> On 11/08/2019 16:18, Mark Hammons wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> I started testing jdk-14-panama+1-15 yesterday, and it seems I've 
>>>>>> run into a bug when using the jextract tool provider. When I try 
>>>>>> to use my jextract build target, i get the following output:
>>>>>>
>>>>>> 1 targets failed
>>>>>> javahelp.jextract java.lang.RuntimeException: In memory 
>>>>>> compilation failed: 
>>>>>> /usr/include/bits/thread_shared_types_lib.java:3: error: cannot 
>>>>>> access usr.include.bits
>>>>>> package usr.include.bits;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/bits/type_headers/struct_timespec_h.java:3: error: 
>>>>>> cannot access usr.include.bits.type_headers
>>>>>> package usr.include.bits.type_headers;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/EGL/eglext_lib.java:3: error: cannot access 
>>>>>> usr.include.EGL
>>>>>> package usr.include.EGL;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /wlroots/clang_support/builtin$_lib.java:3: error: cannot access 
>>>>>> wlroots.clang_support
>>>>>> package wlroots.clang_support;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/X11/keysym_h.java:3: error: cannot access 
>>>>>> usr.include.X11
>>>>>> package usr.include.X11;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/endian_lib.java:3: error: cannot access usr.include
>>>>>> package usr.include;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/wayland/wayland_version_h.java:3: error: cannot 
>>>>>> access usr.include.wayland
>>>>>> package usr.include.wayland;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /wlroots/wlr_output_h.java:3: error: cannot access wlroots
>>>>>> package wlroots;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/KHR/khrplatform_h.java:3: error: cannot access 
>>>>>> usr.include.KHR
>>>>>> package usr.include.KHR;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/pixman_1/pixman_version_lib.java:3: error: cannot 
>>>>>> access usr.include.pixman_1
>>>>>> package usr.include.pixman_1;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/sys/select_lib.java:3: error: cannot access 
>>>>>> usr.include.sys
>>>>>> package usr.include.sys;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /wlroots/backend_headers/session_h.java:3: error: cannot access 
>>>>>> wlroots.backend_headers
>>>>>> package wlroots.backend_headers;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/gnu/stubs_64_lib.java:3: error: cannot access 
>>>>>> usr.include.gnu
>>>>>> package usr.include.gnu;
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/bits/type_headers/__sigset_t_h.java:15: error: 
>>>>>> cannot access usr
>>>>>> public interface __sigset_t_h {
>>>>>> ^
>>>>>>   loc: wrong sig ->a25f5b4b
>>>>>> /usr/include/bits/type_headers/__sigset_t_h.java:10: error: 
>>>>>> cannot find symbol
>>>>>> @NativeHeader(
>>>>>>  ^
>>>>>>   symbol: class NativeHeader
>>>>>> 15 errors
>>>>>>
>>>>>> jdk.jextract/com.sun.tools.jextract.InMemoryJavaCompiler.compile(InMemoryJavaCompiler.java:59) 
>>>>>>
>>>>>> jdk.jextract/com.sun.tools.jextract.Writer.ensureSourcesCompiled(Writer.java:49) 
>>>>>>
>>>>>> jdk.jextract/com.sun.tools.jextract.Writer.writeJar(Writer.java:115)
>>>>>> jdk.jextract/com.sun.tools.jextract.Main.runInternal(Main.java:342)
>>>>>> jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:211)
>>>>>> jdk.jextract/com.sun.tools.jextract.Main$JextractToolProvider.run(Main.java:373) 
>>>>>>
>>>>>> ammonite.$file.build$javahelp$.$anonfun$runTool$1(build.sc:66)
>>>>>>
>>>>>>
>>>>>> I'm fairly certain this isn't an issue in my code, but I could be 
>>>>>> wrong.
>>>>>>
>>>>>> ~Mark
>>>>>>