[foreign] Running tests on Windows
Jorn Vernee
jbvernee at xs4all.nl
Thu Sep 27 17:21:34 UTC 2018
I had tried that as well (looks like I forgot to send an email about
this), but the /link flag has to be passed after all the compiler
arguments [1], since it swallows all the remaining inputs. I can't
control the order of arguments being passed, and AC_CHECK_LIB is passing
the .cpp file as the last argument, so I get an error about missing
source files from the compiler.
Later on those link flags will be passed to the linker directly as well,
which does not recognize the /link flag, so I have been using:
if test "x$TOOLCHAIN_TYPE" != xmicrosoft; then
LIBCLANG_LDFLAGS="-L$CLANG_LIB_PATH"
else
LIBCLANG_LDFLAGS="/LIBPATH $CLANG_LIB_PATH /DEFAULTLIB:libclang"
fi
Without the /link flag.
Cheers,
Jorn
[1] :
https://docs.microsoft.com/en-us/cpp/build/reference/link-pass-options-to-linker?view=vs-2017
Henry Jen schreef op 2018-09-27 19:00:
> If you cannot get AC_CHECK_LIB to work, that means the
> LIBCLANG_LDFLAGS is not setup correctly. Based on the information so
> far, simply add /DEFAULTLIB ourselves should work assuming MSVC will
> ignore the -l.
>
> Something like this, and perhaps also use FIXPATH so we can use unix
> style path in configure.
>
>
> 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
> /DEFAULTLIB:clang"
> + fi
> else
> LIBCLANG_LDFLAGS=""
> fi
>
>
> Cheers,
> Henry
>
>
>> On Sep 27, 2018, at 9:00 AM, Jorn Vernee <jbvernee at xs4all.nl> wrote:
>>
>> I have commented out the AC_CHECK_LIB for now, since I know that the
>> library is there any way, and now getting stuck in
>> /make/lib/Lib-jdk.internal.clang.gmk with the following error during
>> `make images`:
>>
>> LINK : warning LNK4044: unrecognized option '/ljsig'; ignored
>> LINK : fatal error LNK1181: cannot open input file 'j:\LLVM\lib.obj'
>> make[3]: *** [Lib-jdk.internal.clang.gmk:36:
>> /cygdrive/j/cygwin64/home/Jorn/cygwin-projects/panama/build/windows-x86_64-normal-server-release/support/modules_libs/jdk.internal.clang/jclang.dll]
>> Error 1
>> make[2]: *** [make/Main.gmk:215: jdk.internal.clang-libs] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>> Creating support/modules_libs/jdk.management/management_ext.dll from 7
>> file(s)
>>
>> ERROR: Build failed for target 'images' in configuration
>> 'windows-x86_64-normal-server-release' (exit code 2)
>>
>> I can get rid of the warning by changing `-ljsig` to
>> `/DEFAULTLIB:jsig`, but the error stays.
>>
>> The linking is done using the `link-file-relative` macro from
>> /make/common/MakeBase.gmk It might be another pathing issue?
>>
>> Not sure how to debug that further, there doesn't seem to be a `make
>> images` equivalent of config.log where I can look at the commands
>> being run?
>>
>> Jorn
>>
>> Maurizio Cimadamore schreef op 2018-09-27 17:11:
>>> Btw, the issue in my case seems to be cause by the fact that cl.exe
>>> cant locate <time.h> (which is included by clang-c/Index.h header)
>>> Maurizio
>>> On 27/09/18 15:58, Maurizio Cimadamore wrote:
>>>> Got the same on my windows box. I also replaced Magnus's CC
>>>> suggestion with CXX which got me a bit further.
>>>> Maurizio
>>>> On 27/09/18 15:37, Jorn Vernee wrote:
>>>>> AC_CHECK_HEADER seems to use CXX instead of CC. I wasn't seeing the
>>>>> fixpath.exe call in config.log with `CC = "$FIXPATH $CC"`, but it
>>>>> is there when using `CXX="$FIXPATH $CXX"".
>>>>> Checking the header now works, but it's breaking when using
>>>>> `AC_CHECK_LIB`:
>>>>> configure:60545: checking for clang_getClangVersion in -lclang
>>>>> configure:60570:
>>>>> /cygdrive/j/cygwin64/home/Jorn/cygwin-projects/panama/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe
>>>>> -c
>>>>> /cygdrive/j/progra~2/micros~2/2017/buildt~1/vc/tools/msvc/1414~1.264/bin/hostx86/x64/cl
>>>>> -o conftest.exe -I/cygdrive/j/LLVM/include
>>>>> -L/cygdrive/j/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'
>>>>> configure:60570: $? = 2
>>>>> I'm also seeing the following warnings:
>>>>> The following warnings were produced. Repeated here for
>>>>> convenience:
>>>>> WARNING: clang-c/Index.h: accepted by the compiler, rejected by the
>>>>> preprocessor!
>>>>> WARNING: clang-c/Index.h: proceeding with the compiler's result
>>>>> FWIW Not sure if the lib check can work with AC_CHECK_LIB, which
>>>>> seems to add the `-l` on it's own (note the unrecognized option
>>>>> warnings in the log). For the MS linker AFAIK you'd need
>>>>> `/DEFAULTLIB:clang`, or to pass a .lib or .pdb file on the command
>>>>> line instead.
>>>>> Jorn
>>>>> [1] :
>>>>> https://docs.microsoft.com/en-us/cpp/build/reference/linker-options?view=vs-2017
>>>>> Maurizio Cimadamore schreef op 2018-09-27 15:41:
>>>>>> 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