[build2] Using build2 with clang 6 (trunk) on windows

Username I Wanted Was Already Taken usernameiwantedwasalreadytaken at gmail.com
Tue Dec 5 16:20:25 UTC 2017


Hi,

> Could you re-build it with -V and send the output?

Here it is:

C:\Tests\Build2\hello\clang-6>b -V
clang++ -v
clang++ -dumpmachine
clang++ -print-search-dirs
clang++ -x c++ -v -E -
cxx hello at C:\Tests\Build2\hello\clang-6\
  cxx        clang++ at C:\LLVM\build\bin\clang++.exe
  id         clang
  version    6.0.0 (https://llvm.org/git/clang.git
13391081b0b149da4168377ceb1b4af083407d3b) (https://llvm.org/git/llvm.git
48d461fa384512bd9d5e23aba9a2fc828d5154e4)
  major      6
  minor      0
  patch      0
  build      (https://llvm.org/git/clang.git
13391081b0b149da4168377ceb1b4af083407d3b) (https://llvm.org/git/llvm.git
48d461fa384512bd9d5e23aba9a2fc828d5154e4)
  signature  clang version 6.0.0 (https://llvm.org/git/clang.git
13391081b0b149da4168377ceb1b4af083407d3b) (https://llvm.org/git/llvm.git
48d461fa384512bd9d5e23aba9a2fc828d5154e4)
  checksum
dca55fecdd766d5a49b5a212e5ee66aacaf084525b539e106d71a7c4ca13863d
  target     x86_64-microsoft-win32-msvc14.1 (x86_64-pc-windows-msvc)
  inc dirs
    C:\LLVM\build\lib\clang\6.0.0\include\
    C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\ATLMFC\include\
    C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include\
    C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um\
    C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\ucrt\
    C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\shared\
    C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\um\
    C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\winrt\
  lib dirs
    C:\LLVM\build\lib\clang\6.0.0\
bin hello at C:\Tests\Build2\hello\clang-6\
  target     x86_64-microsoft-win32-msvc14.1
lib --version
bin.ar hello at C:\Tests\Build2\hello\clang-6\
  ar         lib at C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64\lib.exe
  id         msvc
  signature  Microsoft (R) Library Manager Version 14.11.25547.0
  checksum
07a750c5776ef44946e2af04c136606cc692655032d453e7f7852cdeb2036eac
clang++ -w -MQ ^ -x c++ -MD -E -frewrite-includes -MF - -o
C:\Tests\Build2\hello\clang-6\hello.exe.obj.ii ../hello/hello.cxx
clang++ -E -x c++ C:\Tests\Build2\hello\clang-6\hello.exe.obj.ii
clang++ -o hello.exe.obj -c -x c++
C:\Tests\Build2\hello\clang-6\hello.exe.obj.ii
clang++ -o hello hello.exe.obj
hello.exe.obj : warning LNK4217: locally defined symbol __std_terminate
imported in function "int `public: static unsigned __int64 __cdecl
std::char_traits<char>::length(char const * const)'::`1'::dtor$2" (?dtor$2@
?0??length@?$char_traits at D@std@@SA_KQEBD at Z@4HA)
hello.exe.obj : warning LNK4217: locally defined symbol _CxxThrowException
imported in function "public: void __cdecl std::ios_base::clear(int,bool)"
(?clear at ios_base@std@@QEAAXH_N at Z)
info: scheduler statistics:

  thread_max_active      8
  thread_max_total       256
  thread_helpers         4
  thread_max_waiting     4

  task_queue_depth       32
  task_queue_full        0

  wait_queue_slots       67
  wait_queue_collisions  0




Those linker warnings are a Clang bug, I think. I've updated the LLVM trunk
and those warnings now appear even if I compile a simple hello world
directly with clang.



> None of these values indicate the runtime being used. There can actually
> be multiple (versions of) toolchains installed in a single VSINSTALLDIR.

You are right. But I think I found a way to know that here:
https://stackoverflow.com/questions/11946294/dump-include-paths-from-g


C:\Tests\Build2\hello\clang-6>clang++ -E -x c++ - -v < nul
clang version 6.0.0 (https://llvm.org/git/clang.git
13391081b0b149da4168377ceb1b4af083407d3b) (https://llvm.org/git/llvm.git
48d461fa384512bd9d5e23aba9a2fc828d5154e4)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\LLVM\build\bin
 "C:\\LLVM\\build\\bin\\clang++.exe" -cc1 -triple
x86_64-pc-windows-msvc19.11.25547 -E -disable-free -disable-llvm-verifier
-discard-value-names -main-file-name - -mrelocation-model pic -pic-level 2
-mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb
-momit-leaf-frame-pointer -v -resource-dir
"C:\\LLVM\\build\\lib\\clang\\6.0.0" -internal-isystem
"C:\\LLVM\\build\\lib\\clang\\6.0.0\\include" -internal-isystem
"C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\ATLMFC\\include"
-internal-isystem "C:\\Program Files (x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.11.25503\\include"
-internal-isystem "C:\\Program Files (x86)\\Windows
Kits\\NETFXSDK\\4.6.1\\include\\um" -internal-isystem "C:\\Program Files
(x86)\\Windows Kits\\10\\include\\10.0.16299.0\\ucrt" -internal-isystem
"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.16299.0\\shared"
-internal-isystem "C:\\Program Files (x86)\\Windows
Kits\\10\\include\\10.0.16299.0\\um" -internal-isystem "C:\\Program Files
(x86)\\Windows Kits\\10\\include\\10.0.16299.0\\winrt" -fdeprecated-macro
-fdebug-compilation-dir "C:\\Tests\\Build2\\hello\\clang-6" -ferror-limit
19 -fmessage-length 120 -fno-use-cxa-atexit -fms-extensions
-fms-compatibility -fms-compatibility-version=19.11.25547 -std=c++14
-fdelayed-template-parsing -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fseh-exceptions -fdiagnostics-show-option -fcolor-diagnostics -o - -x c++ -
clang -cc1 version 6.0.0 based upon LLVM 6.0.0svn default target
x86_64-pc-windows-msvc
#include "..." search starts here:
#include <...> search starts here:
 C:\LLVM\build\lib\clang\6.0.0\include
 C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\ATLMFC\include
 C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include
 C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um
 C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\ucrt
 C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\shared
 C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\um
 C:\Program Files (x86)\Windows Kits\10\include\10.0.16299.0\winrt
End of search list.
# 1 "<stdin>"
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 373 "<built-in>" 3
# 1 "<command line>" 1
# 1 "<built-in>" 2
# 1 "<stdin>" 2


C:\Tests\Build2\hello\clang-6>



The compiler version is in the "-triple" option
(x86_64-pc-windows-msvc19.11.25547) and the Visual Studio version can be
found in the headers (C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Tools\MSVC\14.11.25503\include).


Regards,
Jack




On Tue, Dec 5, 2017 at 12:33 PM, Boris Kolpackov <boris at codesynthesis.com>
wrote:

> Username I Wanted Was Already Taken <usernameiwantedwasalreadytake
> n at gmail.com> writes:
>
> > This worked. The program compiled, but the executable produced does not
> > have a ".exe" extension. If I manually rename "hello" to "hello.exe", it
> > works.
>
> Could you re-build it with -V and send the output?
>
>
> > If we are to assume that (which sounds reasonable), build2 can check the
> > environment for the specific version of the MSVC runtime that is loaded.
> > There is still no guarantee that Clang will use this runtime (since the
> > user may have more than one version of MSVC installed in his machine),
> but
> > I think this is better than nothing.
> >
> > For example, in my setup the following environment variables are defined
> > when running from a development command line:
> >
> > VS150COMNTOOLS=C:\Program Files (x86)\Microsoft Visual
> > Studio\2017\Community\Common7\Tools\
> > VSCMD_ARG_app_plat=Desktop
> > VSCMD_ARG_HOST_ARCH=x64
> > VSCMD_ARG_TGT_ARCH=x64
> > VSCMD_VER=15.4.5
> > VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual
> Studio\2017\Community\
>
> None of these values indicate the runtime being used. There can actually
> be multiple (versions of) toolchains installed in a single VSINSTALLDIR.
> Which one Clang is using is anyone's guess.
>
> I think this value should come from the compiler. It may make sense to
> ask on cfe-dev if there is any way to query it (along with the MSVC and
> SDK bin directories). Failed that, the approach that's based on analyzing
> the header search paths I suggested earlier will have to do.
>
> Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20171205/48ef4d0c/attachment-0001.html>


More information about the users mailing list