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

[Henry Jen]

Updated webrev[1] fix the link issue and revert CXX CXXCPP as suggested by Erik.

[1] https://cr.openjdk.java.net/~henryjen/panama/build-windows/webrev.01/webrev/

Cheers,
Henry


> On Oct 28, 2018, at 9:11 AM, Henry Jen <henry.jen at oracle.com> wrote:
> 
> I think the is caused by link under cygwin on Windows. I’ll double check and fix them.
> 
> Cheers,
> Henry
> 
>> On Oct 28, 2018, at 6:04 AM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>> 
>> 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
>