Jextract tool-provider bug?

[Mark Hammons]

The jextract command generated by the runtool method works. As you noted 
in an earlier email, I have said command printed to the console for 
debugging purposes. I copied it and ran it on its own, without mill or 
the provider interface being involved and it created a proper wlroots.jar.

I am thinking that it's related to how mill is executing its targets, 
since I was able to get a hacked version of sbt using scala 2.12.9 to 
build the project and use jextract on jdk-14-panama. I will look into 
mill's code and discuss with its developers some.

Thanks,

Mark

On 12/08/2019 12:45, Maurizio Cimadamore wrote:
> Btw, I looked around and the
>
> "loc: wrong sig ->" lines seem to be generated deep into the JDK 
> ZipFIleSystem code.
>
> So, very likely that this kicks in when the internal jextract 
> compilation has to access classfiles included in some jar file.
>
> I think first we need to make sure that jextract and the Panama JDK 
> work w/o all the Scala depedencies - is there any way for you to just 
> use jextract from the command line and verify that it works? If that 
> works, next step would be to use the provider interface, but inside a 
> Java program (so that no Scala dependencies are pulled in). If that 
> also work, then I think we need to look deeper at how exactly you are 
> invoking jextract and which JDK is being really used for that (or for 
> the internal compilation executed by jextract).
>
> Maurizio
>
> On 11/08/2019 22:46, Maurizio Cimadamore 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
>>>