[foreign] Running tests on Windows
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Sep 20 09:02:46 UTC 2018
Try this:
diff -r d5dbb455a6b1 make/autoconf/lib-clang.m4
--- a/make/autoconf/lib-clang.m4 Tue Sep 11 18:39:11 2018 +0100
+++ b/make/autoconf/lib-clang.m4 Thu Sep 20 09:59:08 2018 +0100
@@ -60,6 +60,9 @@
VER=`ls $with_libclang/lib/clang/`
CLANG_INCLUDE_AUX_PATH="$with_libclang/lib/clang/$VER/include"
CLANG_LIB_PATH="$with_libclang/lib"
+ BASIC_FIXUP_PATH([CLANG_INCLUDE_PATH])
+ BASIC_FIXUP_PATH([CLANG_LIB_PATH])
+ BASIC_FIXUP_PATH([CLANG_INCLUDE_AUX_PATH])
fi
if test "x$CLANG_INCLUDE_PATH" != "x"; then
Now, if you use only the --with-libclang option with a Unix-style path
(the thing you were trying at first), I believe it should do the right
thing.
Note that we call this BASIC_FIXUP_PATH thingie on all incoming paths
which can possibly contain forward slashes - e.g.
http://hg.openjdk.java.net/jdk/jdk/file/43668e3cae4d/make/autoconf/source-dirs.m4#l49
Maurizio
On 20/09/18 09:44, Maurizio Cimadamore wrote:
> FTR, as I'm looking at other configure files, I've seen
>
> "xwindows" used not "xmicrosoft"
>
> As for the need for double backslash, I don't see any special
> processing done in other configure files prior to the AC_CHECK_HEADER
> call.
>
> The build guide [1] is very explicit that forward slashes should be
> used in options (unlike what you did) and mentions some 'fixpath' tool
> which is used by configure to convert Unix paths into Windows ones. I
> wonder if this could be a bug in that tool?
>
> Seems like this tool is compiled in make/autoconf/basic_windows.m4 -
> it could be worth chasing down as to where the compiled 'fixpath'
> executable is put (should be somewhere in
> build/<conf>/configure-support/) call it with the clang include folder
> with Unix-style forward slash and see whether it spits the correct path.
>
> The source code for this tool can be found here:
>
> http://hg.openjdk.java.net/jdk/jdk/file/43668e3cae4d/make/src/native/fixpath.c
>
>
> Maurizio
>
> [1] -
> http://hg.openjdk.java.net/jdk/jdk/raw-file/43668e3cae4d/doc/building.html#windows
>
>
> On 20/09/18 00:41, Henry Jen wrote:
>> Actually, -I works, and link option need to be passed with /link, but
>> you got the idea…
>>
>> However, -lclang is added by the AC_CHECK_LIB macro, so I am not sure
>> it would work. Need to find a better way to check the lib.
>>
>> diff -r 3fedd3afcd98 make/autoconf/lib-clang.m4
>> --- a/make/autoconf/lib-clang.m4 Mon Sep 17 22:17:08 2018 -0700
>> +++ b/make/autoconf/lib-clang.m4 Wed Sep 19 16:38:06 2018 -0700
>> @@ -68,7 +68,11 @@
>> LIBCLANG_CPPFLAGS=""
>> fi
>> if test "x$CLANG_LIB_PATH" != "x"; then
>> + if test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
>> LIBCLANG_LDFLAGS="-L$CLANG_LIB_PATH"
>> + else
>> + LIBCLANG_LDFLAGS="/link /LIBPATH $CLANG_LIB_PATH"
>> + fi
>> else
>> LIBCLANG_LDFLAGS=""
>> fi
>>
>> Cheers,
>> Henry
>>
>>
>>> On Sep 19, 2018, at 4:17 PM, Henry Jen <henry.jen at oracle.com> wrote:
>>>
>>> Haven’t test it, but try this,
>>>
>>> diff -r 3fedd3afcd98 make/autoconf/lib-clang.m4
>>> --- a/make/autoconf/lib-clang.m4 Mon Sep 17 22:17:08 2018 -0700
>>> +++ b/make/autoconf/lib-clang.m4 Wed Sep 19 16:16:27 2018 -0700
>>> @@ -63,12 +63,20 @@
>>> fi
>>>
>>> if test "x$CLANG_INCLUDE_PATH" != "x"; then
>>> + if test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
>>> LIBCLANG_CPPFLAGS="-I$CLANG_INCLUDE_PATH"
>>> + else
>>> + LIBCLANG_CPPFLAGS="/I $CLANG_INCLUDE_PATH"
>>> + fi
>>> else
>>> LIBCLANG_CPPFLAGS=""
>>> fi
>>> if test "x$CLANG_LIB_PATH" != "x"; then
>>> + if test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
>>> LIBCLANG_LDFLAGS="-L$CLANG_LIB_PATH"
>>> + else
>>> + LIBCLANG_LDFLAGS="/LIBPATH $CLANG_LIB_PATH"
>>> + fi
>>> else
>>> LIBCLANG_LDFLAGS=""
>>> fi
>>>
>>> We still need to fix the copy of DLL.
>>>
>>> Cheers,
>>> Henry
>>>
>>>
>>>> On Sep 19, 2018, at 3:57 PM, Maurizio Cimadamore
>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>> Looks like good progress; tomorrow I'll take a look at some of our
>>>> build files and see if something special is done for mangling
>>>> windows include paths.
>>>>
>>>> Cheers
>>>> Maurizio
>>>>
>>>>
>>>> On 19/09/18 23:12, Jorn Vernee wrote:
>>>>> If I use the following flags:
>>>>>
>>>>> $ bash configure --disable-warnings-as-errors
>>>>> --with-jtreg='/cygdrive/j/Libraries And Tools/jtreg-4.2-b13'
>>>>> --with-libclang-include='J:\\LLVM\\include'
>>>>> --with-libclang-include-aux='J:\\LLVM\\lib'
>>>>> --with-libclang-lib='J:\\LLVM\\lib'
>>>>>
>>>>> (Notice that I'm having to use different path styles)
>>>>>
>>>>> It's detecting the header files, but it's failing on being passed
>>>>> the wrong flags. from config.log (see at the bottom):
>>>>>
>>>>> configure:60248: checking for clang_getClangVersion in -lclang
>>>>> configure:60273:
>>>>> /cygdrive/j/progra~2/micros~2/2017/buildt~1/vc/tools/msvc/1414~1.264/bin/hostx86/x64/cl
>>>>> -o conftest.exe -IJ:\\LLVM\\include -LJ:\\LLVM\\lib
>>>>> conftest.cpp -lclang >&5
>>>>> conftest.cpp
>>>>> Microsoft (R) Incremental Linker Version 14.14.26430.0
>>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>>
>>>>> /out:conftest.exe
>>>>> /out:conftest.exe
>>>>> conftest.obj
>>>>> conftest.obj : error LNK2019: unresolved external symbol
>>>>> clang_getClangVersion referenced in function main
>>>>> conftest.exe : fatal error LNK1120: 1 unresolved externals
>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 19.14.26430 for x64
>>>>> Copyright (C) Microsoft Corporation. All rights reserved.
>>>>>
>>>>> cl : Command line warning D9035 : option 'o' has been deprecated
>>>>> and will be removed in a future release
>>>>> cl : Command line warning D9002 : ignoring unknown option
>>>>> '-LJ:\\LLVM\\lib'
>>>>> cl : Command line warning D9002 : ignoring unknown option '-lclang'
>>>>>
>>>>> That seems to be a simple problem of casing-off windows and
>>>>> passing the right flags, but I call it a night here :)
>>>>>
>>>>> Jorn
>>>>>
>
More information about the panama-dev
mailing list