[foreign] Running tests on Windows

Mon Sep 24 23:38:22 UTC 2018

On 20/09/18 10:29, Magnus Ihse Bursie wrote:
> On 2018-09-20 11:02, Maurizio Cimadamore wrote:
>> 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.
>
> I have not followed the entire conversation, but this part looks sane. 
> As Maurizio says, we should use BASIC_FIXUP_PATH on all paths from 
> configure argument. (And these should, yes indeed, be in unix style). 
> However, this might not be all fixes that are needed. I can help take 
> a look at it, if someone points me to where the problematic code resides.
>
Magnus, I followed up a bit on this, and managed to reproduce the issue.

The underlying issue is that our lib-clang.m4 conf file checks for 
headers in the usual way with AC_CHECK_HEADER. This check relies on 
setting CPPFLAGS and LDFLAGS accordingly. Now, even with the above 
fixups, what you end up with is this:

CLANG_INCLUDE_PATH=/cygdrive/c/progra~1/llvm/include

This is the correct _cygwin_ path, but it's not the correct Windows 
path. In fact, if you try to compile a dummy header that contains this 
(this was also observed by Jorn)

#include <clang-c/Index.h>

with a -I option that includes the above path using the cl.exe compiler 
within cygwin, you get an error because the include file cannot be 
found. The only solution is to use a Windows path, which in cygwin can 
only be done using double backslashes (ugh).

Now, it seems that BASIC_FIXUP_PATH turns windows paths into unix path, 
while here we need the opposite operation. I was under the impression 
that the build configure framework needed to solve this particular issue 
anyway, to check for other headers, but I realized that all calls to 
AC_CHECK_HEADER seems to be Unix-style only. So, is AC_CHECK_HEADER even 
supposed to work under Windows? If not, what should we use in order to 
make our configure script portable?

P.S.
I note that there's also a FIXPATH script which does exactly what we 
need here - but this script seems just to be set by the configure step 
and is probably only used by the proper build, so I don't think we can 
refer to it from here?

Thanks
Maurizio
> /Magnus
>
>
>>
>> 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
>>>>>>>
>>>
>>
>