RFR: [panama foreign] Build tweak to enable build on Windows

[Jorn Vernee]

To add to this (and add missing CCs, sorry about that);

There are 3 libclang.dll files in the build output after running `make 
clean images`;

images\jdk\bin\libclang.dll
jdk\bin\libclang.dll
support\modules_libs\jdk.internal.clang\libclang.dll

All of these files are only 80 bytes in size, while they are supposed to 
be 57+ MB. So I think definitely something is going wrong with the copy. 
I can't find the build system code that does the copying though, so I'm 
not sure how to debug this.

AFAIK we are not building the library from scratch on Windows right? 
Just copying over the .dll from the pre-built distribution?

Jorn

Jorn Vernee schreef op 2018-10-27 19:53:
> Hi Henry,
> 
> I'm testing out this patch and can confirm jextract.exe is being
> built, but I can't use it to extract a header file.
> 
> I'm getting an UnsatisfiedLinkError when loading jclang.dll:
> 
> ```
> PS J:\WS\JNI test\C> jextract Main.h
> Exception in thread "main" java.lang.UnsatisfiedLinkError:
> J:\cygwin64\home\Jorn\cygwin-projects\panama\build\windows-x8
> 6_64-server-release\images\jdk\bin\jclang.dll: %1 is not a valid Win32
> application
>         at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native 
> Method)
>         at
> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2462)
>         at
> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2534)
>         at 
> java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2744)
>         at 
> java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2690)
>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:851)
>         at java.base/java.lang.System.loadLibrary(System.java:1903)
>         at
> jdk.internal.clang/jdk.internal.clang.LibClang.<clinit>(LibClang.java:35)
>         at
> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:74)
>         at 
> jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:411)
>         at 
> jdk.jextract/com.sun.tools.jextract.Context.parse(Context.java:387)
>         at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:251)
>         at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:316)
> ```
> 
> When inspecting jclang.dll with 'dependency walker' (a DLL inspection
> tool [1]) it's giving an error about libclang.dll (a dependency of
> jclang.dll), which tells me "No DOS or PE signature found. This file
> is not a valid 32-bit or 64-bit Windows module.". However, when I open
> the original libclang.dll file from my LLVM installation it _is_ being
> recognized as a valid DLL.
> 
> I think something is going wrong when copying libclang.dll over? I
> have tried manually copying over the libclang.dll file to the jclang
> and jdk/bin folders, which allows me to extract a header file using
> that command line, but when re-running the build the DLL is being
> overwritten again with the corrupted/invalid version.
> 
> Cheers,
> Jorn
> 
> [1] : http://www.dependencywalker.com/
> 
> Henry Jen schreef op 2018-10-26 06:44:
>> Hi,
>> 
>> Please review a web rev[1] that address following,
>> 
>> 1. Copy the essential share library as recorded by the linker
>> following the symbolic link of libclang.so for unix/mac. This leads to
>> only one copy of share library instead of a duplicate copy of
>> libclang.so. It would be nice to have create libclang as a symbolic
>> link, but it’s not needed now.
>> 
>> This issue is what failed the build when using system provided
>> libclang on some systems such as Debian-based Linux distribution.
>> After this patch, Debian-based system can be build as described in
>> README.foreign.
>> 
>> 2. Enable build on Windows. This patch allow build image to be
>> completed successfully and libclang.dll copied to bin as expected.
>> 
>> However, this doesn’t mean binder is working on Windows, it’s simply
>> get the build going and jextract should be functional. Some test still
>> have compiling errors to be fixed, and we don’t have Windows ABI. It’s
>> the first step to allow build on Windows.
>> 
>> I believe a lot of this had been addressed by Jorn, and he actually
>> have made more progress on Windows support. Hopefully this is just the
>> first step and get Windows going.
>> 
>> Cheers,
>> Henry
>> 
>> [1] http://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev