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

[Username I Wanted Was Already Taken]

Hi, and sorry for the delay.

> I've staged a new version that should fix this. Can you give it a try
> and send the -V output?

Ok. Updated build2, now I'm getting a lot of linker errors (see hello.log).


> If everything looks good then can you also try building a library,
> something along these lines:

> exe{hello}: cxx{driver} lib{hello}
> lib{hello}: cxx{hello}


Well, I tried building a library anyways and get the linker errors too:

C:\Tests\Build2\libhello\msvc-17>b
c++ ../hello/cxx{driver}
c++ ../hello/cxx{hello}
ld liba{hello}
ld exe{hello}

C:\Tests\Build2\libhello\msvc-17>cd ..\clang-6

C:\Tests\Build2\libhello\clang-6>b
c++ ../hello/cxx{driver}
c++ ../hello/cxx{hello}
ld liba{hello}
ld exe{hello}
LINK : error LNK2001: unresolved external symbol mainCRTStartup
hello.lib(hello.lib.obj) : error LNK2019: unresolved external symbol
__acrt_iob_func referenced in function printf
hello.lib(hello.lib.obj) : error LNK2019: unresolved external symbol
__stdio_common_vfprintf referenced in function _vfprintf_l
hello.exe : fatal error LNK1120: 3 unresolved externals
info: failed to update dir{.\}



Now here there are less linker errors, but I think this is because in this
project I'm using printf instead of std::cout to output the message. The
full log is in libhello.log. It was generated by the following commands:

C:\Tests\Build2\libhello\clang-6>b -V 2> libhello.log
C:\Tests\Build2\libhello\clang-6>b config.bin.lib=static -V 2>> libhello.log
C:\Tests\Build2\libhello\clang-6>b config.bin.lib=shared -V 2>> libhello.log



> Do you know if the 5.0 release is usable/stable for this target?

I just tested the 5.0 release, and I get the same linker errors.

> I've written to cfe-dev to see if they will be willing to fix this:

Ok.

Regards,
Jack




On Wed, Dec 6, 2017 at 8:01 AM, Boris Kolpackov <boris at codesynthesis.com>
wrote:

> Username I Wanted Was Already Taken <usernameiwantedwasalreadytake
> n at gmail.com> writes:
>
> > clang++ -o hello hello.exe.obj
>
> Ok, this isn't right. There should be the .exe extension and we should
> be using link.exe directly.
>
> I've staged a new version that should fix this. Can you give it a try
> and send the -V output?
>
> If everything looks good then can you also try building a library,
> something along these lines:
>
> exe{hello}: cxx{driver} lib{hello}
> lib{hello}: cxx{hello}
>
> And then try both static and shared:
>
> b config.bin.lib=static -V
> b config.bin.lib=shared -V
>
>
> > 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.
>
> Yes, and that's the reason I am reluctant to make a CI machine for this
> configuration -- half of the time I will be investigating Clang bugs.
> Do you know if the 5.0 release is usable/stable for this target?
>
>
> > clang++.exe -cc1 -triple x86_64-pc-windows-msvc19.11.25547
>
> Interesting. So they do know the compiler version and internally
> even slap it onto the target triplet (which is the wrong thing to
> do IMO; it should be the runtime version). But for some reason
> they omit it from the -dumpmachine output. I've written to cfe-dev
> to see if they will be willing to fix this:
>
> http://lists.llvm.org/pipermail/cfe-dev/2017-December/056240.html
>
> Boris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.build2.org/archives/users/attachments/20171207/c9f2597c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hello.log
Type: application/octet-stream
Size: 45109 bytes
Desc: not available
URL: <https://lists.build2.org/archives/users/attachments/20171207/c9f2597c/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libhello.log
Type: application/octet-stream
Size: 9740 bytes
Desc: not available
URL: <https://lists.build2.org/archives/users/attachments/20171207/c9f2597c/attachment-0003.obj>