[foreign] Running tests on Windows
Maurizio Cimadamore
maurizio.cimadamore at oracle.com
Thu Sep 27 13:41:40 UTC 2018
On 27/09/18 14:35, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-25 01:38, Maurizio Cimadamore wrote:
>>
>>
>>
>> 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?
>
> Hi,
>
> Sorry for not having had time to look at this yet.
>
> The solution should be to use FIXPATH at all times when compiling on
> Windows if using local paths, even in the configure script. It might
> be the case that we have not had to do this as of yet, so it might not
> work out of the box. :-( But I thought we set up CC to "$FIXPATH $CC"
> on Windows, so I thought it should work by itself.
>
> To get around the mess of windows and unix style paths, the decision
> was made to use only unix paths *all the time*. The duct tape needed
> to get this to work is the fixpath launcher, which takes a
> command-line with unix paths and converts it to windows paths at the
> very last moment before launching the executable.
>
> Does things work better if you to:
> CC="$FIXPATH $CC"
> before your AC_CHECK_HEADER?
I'll give this a try - thanks
Maurizio
>
> /Magnus
>
>
>>
>> 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
>>>>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the panama-dev
mailing list