[foreign] libclang.dll not copied to JDK image on Windows

[Henry Jen]

I remember this was fixed by copy using CLANG_LIBNAME, 

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

but perhaps it got reverted.

Another follow up that wasn’t pushed is following to make sure 

https://cr.openjdk.java.net/~henryjen/panama/libclang-symlinks/webrev/

Cheers,
Henry

> On Jan 16, 2019, at 7:30 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> Yeah - noted the same, working on a fix
> 
> Maurizio
> 
> On 16/01/2019 15:22, Jorn Vernee wrote:
>> Afaik the `libclang.dll` file is supposed to be in the `bin` folder after building. It's not copied there for me either currently, but jextract works since I have the llvm/bin folder on the PATH, so the library can be loaded from there. The copying was supposedly working when the Windows build patch came in [1]
>> 
>>     "This patch allow build image to be completed successfully and libclang.dll copied to bin as expected."
>> 
>> And I remember verifying that as well. I guess I just never noticed the regression since I have the llvm/bin folder on my PATH.
>> 
>> Jorn
>> 
>> [1] : https://mail.openjdk.java.net/pipermail/panama-dev/2018-October/003003.html
>> 
>> Maurizio Cimadamore schreef op 2019-01-16 15:07:
>>> As the subject implies, there seems to be a build setup issue on
>>> windows, as the image I've built doesn't have libclang.dll under the
>>> images 'lib' folder.
>>> 
>>> As a result jextract fails with the simplest of example:
>>> 
>>> $ build/windows-x64/images/jdk/bin/jextract.exe foo.h
>>> Exception in thread "main" java.lang.UnsatisfiedLinkError:
>>> C:\cygwin64\home\MCIMADAM\panama\closed\build\windows-x64\images\jdk\bin\jclang.dll: 
>>> Can't find dependent libraries
>>>         at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
>>>         at
>>> java.base/java.lang.ClassLoader$NativeLibrary.load(ClassLoader.java:2451) 
>>>         at
>>> java.base/java.lang.ClassLoader$NativeLibrary.loadLibrary(ClassLoader.java:2523) 
>>>         at java.base/java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2733)
>>>         at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2679)
>>>         at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:849)
>>>         at java.base/java.lang.System.loadLibrary(System.java:1905)
>>>         at
>>> jdk.internal.clang/jdk.internal.clang.LibClang.<clinit>(LibClang.java:35) 
>>>         at
>>> jdk.jextract/com.sun.tools.jextract.parser.Parser.parse(Parser.java:71)
>>>         at
>>> jdk.jextract/com.sun.tools.jextract.JextractTool.processHeaders(JextractTool.java:58) 
>>>         at jdk.jextract/com.sun.tools.jextract.Main.run(Main.java:264)
>>>         at jdk.jextract/com.sun.tools.jextract.Main.main(Main.java:334)
>>> 
>>> 
>>> Is this a known issue? This is what I get in the spec.gmk file:
>>> 
>>> CLANG_LIB_PATH:=/cygdrive/c/progra~1/llvm/lib
>>> CLANG_INCLUDE_PATH:=/cygdrive/c/progra~1/llvm/include
>>> CLANG_INCLUDE_AUX_PATH:=/cygdrive/c/progra~1/llvm/lib/clang/70fe6e~1.0/include 
>>> CLANG_LIBNAME:=/cygdrive/c/progra~1/llvm/bin/libclang.dll
>>> LIBCLANG_CPPFLAGS:=-I/cygdrive/c/progra~1/llvm/include
>>> LIBCLANG_LDFLAGS:=/LIBPATH:/cygdrive/c/progra~1/llvm/lib
>>> LIBCLANG_LIBS:=/cygdrive/c/progra~1/llvm/lib/libclang.lib
>>> 
>>> All paths involved seem to exist.
>>> 
>>> Maurizio