clang-win, again

classic Classic list List threaded Threaded
75 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

clang-win, again

Boost - Dev mailing list
Has anyone succeeded in getting clang-cl.exe working under b2? I've
installed llvm-6.0.1, added it to PATH, put

    using clang-win : : : <compatibility>vc14 ;

in my user-config, and what I get is:



C:\boost-git\develop\libs\smart_ptr\test>b2 toolset=clang-win
sp_interlocked_test

warning: mismatched versions of Boost.Build engine and core
warning: Boost.Build engine (b2) is 2015.07.00
warning: Boost.Build core (at C:/boost-git/develop/tools/build/src) is
2018.02-git

C:/boost-git/develop/tools/build/src/tools\msvc.jam:1087: in
set-setup-command
*** argument error
* rule virtual-target.from-file ( file : file-loc : project )
* called with: (  : /C:/boost-git/develop/libs/smart_ptr/test :
object(project-t
arget)@129 )
* missing argument file
C:/boost-git/develop/tools/build/src/build\virtual-target.jam:970:see
definition
of rule 'virtual-target.from-file' being called
C:/boost-git/develop/tools/build/src/tools\msvc.jam:652: in
clang-win.compile.c+
+
C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in
modules.call-in
C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call
C:/boost-git/develop/tools/build/src/build\virtual-target.jam:902: in
execute
C:/boost-git/develop/tools/build/src/build\virtual-target.jam:821: in
class@acti
on.actualize
C:/boost-git/develop/tools/build/src/build\virtual-target.jam:332: in
actualize-
action
C:/boost-git/develop/tools/build/src/build\virtual-target.jam:518: in
actualize-
no-scanner
C:/boost-git/develop/tools/build/src/build\virtual-target.jam:142: in
class@virt
ual-target.actualize
C:/boost-git/develop/tools/build/src/build\configure.jam:258: in
try-find-build
C:/boost-git/develop/tools/build/src/build\configure.jam:396: in
find-builds-raw

C:/boost-git/develop/tools/build/src/build\configure.jam:455: in
configure.find-
builds
C:/boost-git/develop\boostcpp.jam:734: in boostcpp.deduce-address-model
C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in
modules.call-in
C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in indirect.call
C:/boost-git/develop/tools/build/src/build\property.jam:144: in
property.evaluat
e-conditionals-in-context
C:/boost-git/develop/tools/build/src/build\targets.jam:1087: in
evaluate-require
ments
C:/boost-git/develop/tools/build/src/build\targets.jam:1121: in
common-propertie
s2
C:/boost-git/develop/tools/build/src/build\targets.jam:1017: in
targets.common-p
roperties
C:/boost-git/develop/tools/build/src/build\targets.jam:1313: in
class@basic-targ
et.generate
C:/boost-git/develop/tools/build/src/build\targets.jam:812: in
generate-really
C:/boost-git/develop/tools/build/src/build\targets.jam:784: in
class@main-target
.generate
C:/boost-git/develop/tools/build/src\build-system.jam:797: in load
C:\boost-git\develop\tools\build\src/kernel\modules.jam:295: in import
C:\boost-git\develop\tools\build\src/kernel/bootstrap.jam:139: in
boost-build
C:\boost-git\develop\boost-build.jam:17: in module scope


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On 8/11/2018 6:22 PM, Peter Dimov via Boost wrote:
> Has anyone succeeded in getting clang-cl.exe working under b2? I've
> installed llvm-6.0.1, added it to PATH, put
>
>     using clang-win : : : <compatibility>vc14 ;

I use this:

using clang : 6.0cl : C:/Utilities/LLVM/601/x32/bin/clang++
  :
  <cxxflags>-fmacro-backtrace-limit=0
  <cxxflags>-Wno-invalid-token-paste
  <compileflags>-fmsc-version=1900
  <compileflags>--target=i686-pc-windows-msvc
  <linkflags>--target=i686-pc-windows-msvc
  <linkflags>-fuse-ld=lld
  ;

My batch file which uses this puts C:\Utilities\LLVM\601\x32\bin
first in the path and also invokes the correct 'vcvarsall.bat x86'
command. The command line uses 'toolset=clang-6.0cl'. I have not tried
it yet with VS2017.

>
> in my user-config, and what I get is:
>
>
>
> C:\boost-git\develop\libs\smart_ptr\test>b2 toolset=clang-win
> sp_interlocked_test
>
> warning: mismatched versions of Boost.Build engine and core
> warning: Boost.Build engine (b2) is 2015.07.00
> warning: Boost.Build core (at C:/boost-git/develop/tools/build/src) is
> 2018.02-git
>
> C:/boost-git/develop/tools/build/src/tools\msvc.jam:1087: in
> set-setup-command
> *** argument error
> * rule virtual-target.from-file ( file : file-loc : project )
> * called with: (  : /C:/boost-git/develop/libs/smart_ptr/test :
> object(project-t
> arget)@129 )
> * missing argument file
> C:/boost-git/develop/tools/build/src/build\virtual-target.jam:970:see
> definition
> of rule 'virtual-target.from-file' being called
> C:/boost-git/develop/tools/build/src/tools\msvc.jam:652: in
> clang-win.compile.c+
> +
> C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in
> modules.call-in
> C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in
> indirect.call
> C:/boost-git/develop/tools/build/src/build\virtual-target.jam:902: in
> execute
> C:/boost-git/develop/tools/build/src/build\virtual-target.jam:821: in
> class@acti
> on.actualize
> C:/boost-git/develop/tools/build/src/build\virtual-target.jam:332: in
> actualize-
> action
> C:/boost-git/develop/tools/build/src/build\virtual-target.jam:518: in
> actualize-
> no-scanner
> C:/boost-git/develop/tools/build/src/build\virtual-target.jam:142: in
> class@virt
> ual-target.actualize
> C:/boost-git/develop/tools/build/src/build\configure.jam:258: in
> try-find-build
> C:/boost-git/develop/tools/build/src/build\configure.jam:396: in
> find-builds-raw
>
> C:/boost-git/develop/tools/build/src/build\configure.jam:455: in
> configure.find-
> builds
> C:/boost-git/develop\boostcpp.jam:734: in boostcpp.deduce-address-model
> C:/boost-git/develop/tools/build/src/kernel\modules.jam:107: in
> modules.call-in
> C:/boost-git/develop/tools/build/src/util\indirect.jam:105: in
> indirect.call
> C:/boost-git/develop/tools/build/src/build\property.jam:144: in
> property.evaluat
> e-conditionals-in-context
> C:/boost-git/develop/tools/build/src/build\targets.jam:1087: in
> evaluate-require
> ments
> C:/boost-git/develop/tools/build/src/build\targets.jam:1121: in
> common-propertie
> s2
> C:/boost-git/develop/tools/build/src/build\targets.jam:1017: in
> targets.common-p
> roperties
> C:/boost-git/develop/tools/build/src/build\targets.jam:1313: in
> class@basic-targ
> et.generate
> C:/boost-git/develop/tools/build/src/build\targets.jam:812: in
> generate-really
> C:/boost-git/develop/tools/build/src/build\targets.jam:784: in
> class@main-target
> .generate
> C:/boost-git/develop/tools/build/src\build-system.jam:797: in load
> C:\boost-git\develop\tools\build\src/kernel\modules.jam:295: in import
> C:\boost-git\develop\tools\build\src/kernel/bootstrap.jam:139: in
> boost-build
> C:\boost-git\develop\boost-build.jam:17: in module scope


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
Edward Diener wrote:

> On 8/11/2018 6:22 PM, Peter Dimov via Boost wrote:
> > Has anyone succeeded in getting clang-cl.exe working under b2? I've
> > installed llvm-6.0.1, added it to PATH, put
> >
> >     using clang-win : : : <compatibility>vc14 ;
>
> I use this:
>
> using clang : 6.0cl : C:/Utilities/LLVM/601/x32/bin/clang++
>   :
>   <cxxflags>-fmacro-backtrace-limit=0
>   <cxxflags>-Wno-invalid-token-paste
>   <compileflags>-fmsc-version=1900
>   <compileflags>--target=i686-pc-windows-msvc
>   <linkflags>--target=i686-pc-windows-msvc
>   <linkflags>-fuse-ld=lld
>   ;

This kind of works, even without the options, using just the simple

    using clang ;

and without setting up any MSVC build environment. clang++ finds MSVC 2017
on its own.

But unfortunately any dynamic_cast use fails with

    undefined symbol: __imp___RTDynamicCast

regardless of whether I use -fuse-ld=lld. :-/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On 8/11/2018 9:12 PM, Peter Dimov via Boost wrote:

> Edward Diener wrote:
>> On 8/11/2018 6:22 PM, Peter Dimov via Boost wrote:
>> > Has anyone succeeded in getting clang-cl.exe working under b2? I've
>> > installed llvm-6.0.1, added it to PATH, put
>> >
>> >     using clang-win : : : <compatibility>vc14 ;
>>
>> I use this:
>>
>> using clang : 6.0cl : C:/Utilities/LLVM/601/x32/bin/clang++
>>   :
>>   <cxxflags>-fmacro-backtrace-limit=0
>>   <cxxflags>-Wno-invalid-token-paste
>>   <compileflags>-fmsc-version=1900
>>   <compileflags>--target=i686-pc-windows-msvc
>>   <linkflags>--target=i686-pc-windows-msvc
>>   <linkflags>-fuse-ld=lld
>>   ;
>
> This kind of works, even without the options, using just the simple
>
>     using clang ;
>
> and without setting up any MSVC build environment. clang++ finds MSVC
> 2017 on its own.
>
> But unfortunately any dynamic_cast use fails with
>
>     undefined symbol: __imp___RTDynamicCast
>
> regardless of whether I use -fuse-ld=lld. :-/

I agree. It is not very good. In general clang under Windows, whether
using gcc or vc++ has many problems, but almost always with the linker
and rarely with the compiler, although it still can not handle VMD with
its preprocessor. I gave up trying to get the clang developers to pay
any attention to any of this a while ago.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On Sun, 12 Aug 2018 at 04:52, Edward Diener via Boost <[hidden email]>
wrote:

> I agree. It is not very good. In general clang under Windows, whether
> using gcc or vc++ has many problems


I don't understand what you mean with this, you are using clang and lld,
and you arer talking about gcc and vc?


> , but almost always with the linker
> and rarely with the compiler, although it still can not handle VMD with
> its preprocessor. I gave up trying to get the clang developers to pay
> any attention to any of this a while ago.
>

Clang 7.0 RC is out, other than the filesystem thing, there don't seem to
be many issues. You could give that a spin. I always use trunk and there
are improvements (also in constexpr f.e.).

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 12 Aug 2018 at 01:23, Peter Dimov via Boost <[hidden email]>
wrote:

> Has anyone succeeded in getting clang-cl.exe working under b2?
>

Only sideways related, someone (Jason) is working on creating the option to
use the clang tool chain with vcpkg, which supports boost (in a sort of
modular way, as modular as it gets, given the current structure of boost)
and much more, with new libraries being added almost on a daily basis (or
at least a couple a week).

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 8/12/2018 12:09 AM, degski via Boost wrote:
> On Sun, 12 Aug 2018 at 04:52, Edward Diener via Boost <[hidden email]>
> wrote:
>
>> I agree. It is not very good. In general clang under Windows, whether
>> using gcc or vc++ has many problems
>
>
> I don't understand what you mean with this, you are using clang and lld,
> and you arer talking about gcc and vc?

When using clang-cl the vc++ compiler is the backend. It is possible to
use clang with mingw(-64)/gcc as the backend on Windows. In either case
clang has almost always exhibited its problems in the linking stage
rather than the compiler stage due to the fact that it sometimes
mismatches the names it creates with the backend compiler's libraries it
uses. In one case on Windows, attempting to run the VMD tests, it fails
pretty miserably in the preprocessor stage whereas mingw(-64)/gcc
succeeds completely.

>
>
>> , but almost always with the linker
>> and rarely with the compiler, although it still can not handle VMD with
>> its preprocessor. I gave up trying to get the clang developers to pay
>> any attention to any of this a while ago.
>>
>
> Clang 7.0 RC is out, other than the filesystem thing, there don't seem to
> be many issues. You could give that a spin. I always use trunk and there
> are improvements (also in constexpr f.e.).

Even building clang on Windows has been problematical for a while now
and past appeals to clang developers about this have resulted in silence
on their end of things. Getting clang to work on Windows has been very
low priority for their developers in the past. Others can spend time
reporting problems about their Windows implementation to clang
developers if they want, but I have given up that cause.

>
> degski
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On Sun, 12 Aug 2018 at 14:56, Edward Diener via Boost <[hidden email]>
wrote:

> When using clang-cl the vc++ compiler is the backend.


We must be living in parallel worlds. If you use Clang/LLVM, LLVM is
obviously the backend. If you download and install
https://releases.llvm.org/6.0.1/LLVM-6.0.1-win64.exe the backend is LLVM.
BUT, and that's where trouble (in relation to Boost) starts, is that it
will use the VC STL. There is AFAICS no particular problem with the VC STL
(I'm talking current release here, 15.7.6), but there is, with the way
Boost deals with it when invoked with clang as a compiler on windows (non
mingw), particularly boost/type_traits, has problems. Clang signals f.e.
(as it did over a year ago) is_assignable not found, did you mean
std::is_assignable, YES I DO. I found this issue today, Boost.Wave does not
compile because of this and so don't do 9 other libraries. I've written to
the list about this issue in boost/type_traits in detail over a year ago
(from memory).

It is possible to
> use clang with mingw(-64)/gcc as the backend on Windows. In either case
> clang has almost always exhibited its problems in the linking stage
> rather than the compiler stage due to the fact that it sometimes
> mismatches the names it creates with the backend compiler's libraries it
> uses. In one case on Windows, attempting to run the VMD tests, it fails
> pretty miserably in the preprocessor stage whereas mingw(-64)/gcc
> succeeds completely.
>

Why would you even like to do that, LLVM generates native code directly (as
it does for Rust). Both link (the vc exe, but not with LTCG, or llvm lto,
thin or full) and lld will work (lld also with lto, thin or full, if you
compile the code with the correct flags). There's no reason to believe (or
a need for that) it works with mingw/gcc, AFAICS. Clang is a compiler, it
does not do any name matching (it eats a cpp-file and spits out LLVM-ir),
the problems must be in the rest of the (your) tools.

I gave up trying to get the clang developers to pay any attention to any of
> this a while ago.
>

They are a gated community just like Boost and respond similarly, just feel
welcomed and all is good.

Even building clang on Windows has been problematical for a while now
> and past appeals to clang developers about this have resulted in silence
> on their end of things.


I use clang/cmake/ninja, and it works AFAICS. That's what they guarantee,
Clang/LLVM should build with Clang stable (the one from the download link),
that's it, no more. vcpkg has llvm (including clang) as well, by the way,
so if you don't want to download, or would like to add your own flavour,
knock yourself out. There is also some stuff (just look it up on llvm.org)
to bootstrap clang with vc and then (totally automated) build clang with
the clang you just built. This works, I tried it (and succeeded) 3 days ago.

Getting clang to work on Windows has been very
> low priority for their developers in the past. Others can spend time
> reporting problems about their Windows implementation to clang
> developers if they want, but I have given up that cause.
>

It seems they are very focused on the compiler and not on any tooling.
Having said that, it works perfectly fine from where I'm standing. I use
clang/llvm with VS17 on a daily basis without any issue, which is
unsurprising [but great] as MS uses clang to check how their STL is doing.

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On 8/12/2018 8:59 AM, degski via Boost wrote:
> On Sun, 12 Aug 2018 at 14:56, Edward Diener via Boost <[hidden email]>
> wrote:
>
>> When using clang-cl the vc++ compiler is the backend.
>
>
> We must be living in parallel worlds. If you use Clang/LLVM, LLVM is
> obviously the backend. If you download and install
> https://releases.llvm.org/6.0.1/LLVM-6.0.1-win64.exe the backend is LLVM.

You are correct. I mixed up "backend" and "frontend".

> BUT, and that's where trouble (in relation to Boost) starts, is that it
> will use the VC STL. There is AFAICS no particular problem with the VC STL
> (I'm talking current release here, 15.7.6), but there is, with the way
> Boost deals with it when invoked with clang as a compiler on windows (non
> mingw), particularly boost/type_traits, has problems. Clang signals f.e.
> (as it did over a year ago) is_assignable not found, did you mean
> std::is_assignable, YES I DO. I found this issue today, Boost.Wave does not
> compile because of this and so don't do 9 other libraries. I've written to
> the list about this issue in boost/type_traits in detail over a year ago
> (from memory).

I do not think these are Boost problems, but clang on Windows problems.
Boost.config does identify clang as the compiler on Windows correctly,
whether the frontend is VC++ libraries or mingw(-64) libraries.

>
> It is possible to
>> use clang with mingw(-64)/gcc as the backend on Windows. In either case
>> clang has almost always exhibited its problems in the linking stage
>> rather than the compiler stage due to the fact that it sometimes
>> mismatches the names it creates with the backend compiler's libraries it
>> uses. In one case on Windows, attempting to run the VMD tests, it fails
>> pretty miserably in the preprocessor stage whereas mingw(-64)/gcc
>> succeeds completely.
>>
>
> Why would you even like to do that >, LLVM generates native code directly (as
> it does for Rust). Both link (the vc exe, but not with LTCG, or llvm lto,
> thin or full) and lld will work (lld also with lto, thin or full, if you
> compile the code with the correct flags). There's no reason to believe (or
> a need for that) it works with mingw/gcc, AFAICS. Clang is a compiler, it
> does not do any name matching (it eats a cpp-file and spits out LLVM-ir),
> the problems must be in the rest of the (your) tools.

We don't all love the broken VC++ emulated preprocessor of clang with
vc++ as you do.

>
> I gave up trying to get the clang developers to pay any attention to any of
>> this a while ago.
>>
>
> They are a gated community just like Boost and respond similarly, just feel
> welcomed and all is good.

Good. Then I am sure you will be wiling to deal with them when someone
reports problems trying to use clang on Windows with Boost, as Peter has
just done. Please tell us what the clang developers tell us about this
latest problem. It would be greatly appreciated.

>
> Even building clang on Windows has been problematical for a while now
>> and past appeals to clang developers about this have resulted in silence
>> on their end of things.
>
>
> I use clang/cmake/ninja, and it works AFAICS. That's what they guarantee,
> Clang/LLVM should build with Clang stable (the one from the download link),
> that's it, no more. vcpkg has llvm (including clang) as well, by the way,
> so if you don't want to download, or would like to add your own flavour,
> knock yourself out. There is also some stuff (just look it up on llvm.org)
> to bootstrap clang with vc and then (totally automated) build clang with
> the clang you just built. This works, I tried it (and succeeded) 3 days ago.

I had also used the clang/cmake/ninja toolchain to build clang on
Windows from source. When it did not work due to build errors I would
report the problems to clang developers. While occasionally someone
would answer about some bug on the Windows side of clang development,
more often there was no response. Eventually I completely stopped trying
to build clang on Windows from source. Who need such headaches when
developers generally don't care.

>
> Getting clang to work on Windows has been very
>> low priority for their developers in the past. Others can spend time
>> reporting problems about their Windows implementation to clang
>> developers if they want, but I have given up that cause.
>>
>
> It seems they are very focused on the compiler and not on any tooling.
> Having said that, it works perfectly fine from where I'm standing. I use
> clang/llvm with VS17 on a daily basis without any issue, which is
> unsurprising [but great] as MS uses clang to check how their STL is doing.

Good for you.

>
> degski
>



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> BUT, and that's where trouble (in relation to Boost) starts, is that it
> will use the VC STL. There is AFAICS no particular problem with the VC STL
> (I'm talking current release here, 15.7.6), but there is, with the way
> Boost deals with it when invoked with clang as a compiler on windows (non
> mingw), particularly boost/type_traits, has problems.

There are currently only 4 type_traits tests that fail with clang/llvm
on windows - all related to msvc compatibility.

PR's are of course always welcome.

John.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 12 Aug 2018 at 16:18, Edward Diener via Boost <[hidden email]>
wrote:

> I do not think these are Boost problems, but clang on Windows problems.
> Boost.config does identify clang as the compiler on Windows correctly,
> whether the frontend is VC++ libraries or mingw(-64) libraries.
>

I'm not saying Boost.Config does not identify Clang on Windows correctly.
The problem lies in the various libraries dealing with this information.
The build does mention a lot of linux refs though, so even there I'm not so
sure. I get things like
C:\boost-build\boost\bin.v2\libs\atomic\build\clng-lnx-8.0.0\rls\lnk-sttc .
It certainly looks suspicious, but heck 26 libraries do build.

We don't all love the broken VC++ emulated preprocessor of clang with
> vc++ as you do.
>

I don't love it, but writing modern C++17 doesn't need much pre-processing,
so that's what I try to do.

Good. Then I am sure you will be wiling to deal with them when someone
> reports problems trying to use clang on Windows with Boost, as Peter has
> just done. Please tell us what the clang developers tell us about this
> latest problem. It would be greatly appreciated.
>

I'm outside the gate too, so no. I've been writing about this for long time
now, but it gets mostly ignored.
To prove that point: I posted this
https://lists.boost.org/Archives/boost/2018/07/242444.php on the 8th of
Juli. Nobody answered that and that question has as it turns out yesterday
(from a post by that same Peter) to be a very simple answer, thanks Peter!.
In the meanwhile I already deleted the stuff to what that was relevant.

> It seems they are very focused on the compiler and not on any tooling.
> > Having said that, it works perfectly fine from where I'm standing. I use
> > clang/llvm with VS17 on a daily basis without any issue, which is
> > unsurprising [but great] as MS uses clang to check how their STL is
> doing.
>
> Good for you.
>

?

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Sun, 12 Aug 2018 at 21:21, John Maddock via Boost <[hidden email]>
wrote:

> There are currently only 4 type_traits tests that fail with clang/llvm
> on windows - all related to msvc compatibility.
>

The (type of) errors I refer to is where f.e. std::is_assignable is clearly
available on compiler/platform but the boost one is reported not found,
while the obvious std::is_assignable (that should be used) is not used.
This was in wave, but I'm sure there are more of the same type of errors as
the above, they probably all just need 1 fix, i.e. it's a class of errors.

Wasn't this the/a similar symptom in Regex, it's too long ago cannot
remember. There the reason was that the detection was too simple, for the
now more complex situation that has been created (by the arrival of
Clang/VC STL). Just checking for _MSC_VER no longer does the Job, there
needs to be a check for __clang__ and/or possibly __GNUC__ depending on
what one is trying to determine.

I'll build again saving the build output to file and do some diggin'.

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
I went through the build log and these things pop up.

graph, locale, thread and wave fail because of:

In file included from libs\wave\src\instantiate_predef_macros.cpp:23:
In file included from
.\boost/wave/grammars/cpp_predef_macros_grammar.hpp:14:
In file included from .\boost/spirit/include/classic_core.hpp:11:
In file included from .\boost/spirit/home/classic/core.hpp:28:
In file included from .\boost/spirit/home/classic/core/match.hpp:15:
In file included from .\boost/optional.hpp:15:
In file included from .\boost/optional/optional.hpp:47:
In file included from .\boost/type_traits/is_nothrow_move_assignable.hpp:15:
.\boost/type_traits/has_trivial_move_assign.hpp:49:4: error: no template
named 'is_assignable'; did you mean 'std::is_assignable'?
   BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T)

coroutine fails because threads failed.

log fails because of:

In file included from libs\log\src\syslog_backend.cpp:38:
In file included from .\boost/log/sinks/syslog_backend.hpp:30:
In file included from .\boost/log/sinks/basic_sink_backend.hpp:22:
In file included from .\boost/log/core/record_view.hpp:23:
In file included from .\boost/log/attributes/attribute_value_set.hpp:26:
.\boost/log/attributes/attribute.hpp:69:5: error: declaration of anonymous
struct must be a definition
    struct BOOST_LOG_NO_VTABLE BOOST_SYMBOL_VISIBLE impl :

log_setup fails because log fails.

serialization and wserialization fail because:

In file included from libs\serialization\src\xml_grammar.cpp:19:
In file included from .\boost/archive/impl/basic_xml_grammar.hpp:53:
In file included from .\boost/spirit/include/classic_rule.hpp:11:
In file included from
.\boost/spirit/home/classic/core/non_terminal/rule.hpp:33:
In file included from
.\boost/spirit/home/classic/core/non_terminal/impl/rule.ipp:22:
In file included from .\boost/spirit/home/classic/core/parser.hpp:14:
In file included from
.\boost/spirit/home/classic/core/scanner/scanner.hpp:14:
In file included from .\boost/spirit/home/classic/core/match.hpp:15:
In file included from .\boost/optional.hpp:15:
In file included from .\boost/optional/optional.hpp:47:
In file included from .\boost/type_traits/is_nothrow_move_assignable.hpp:15:
.\boost/type_traits/has_trivial_move_assign.hpp:49:4: error: no template
named 'is_volatile' in namespace 'boost'; did you mean 'std::is_volatile'?
   BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T)

and the is_assignable-problem as in the above.

I'm not building math, mpi and python.

There is this linker error when I try to use random:

;1>  libboost_system-clang80-mt-sd-x64-1_68.lib(error_code.obj) : error
LNK2019: unresolved external symbol __imp___RTDynamicCast referenced in
function "public: virtual bool __cdecl
boost::system::error_category::std_category::equivalent(class
std::error_code const &,int)const " (?equivalent@std_category
@error_category@system@boost@@UEBA_NAEBVerror_code@std@@H@Z)

which is exactly the same function Peter reported to have a problem with.

Besides that, it's bizarre that all is built with lnx in the name, although
not without error, some stuff does seem to work (the boost::random_device
was found f.e.).

degski

PS1: for copying the boost header tree, the copy command is used per file,
with individual output per line. There is the xcopy command, it can copy
whole sub-trees, with several options in case the destination file exists
(copy when newer only) or not to copy a file if it doesn't exists, it can
also skip empty directories, and last but not least it can be silenced to
not output anything. Most of the time it takes to build boost is consumed
by the copying, it also generates 82'000
 lines of output.
PS2: I did some more rain-dancing, chanted hare-hare and did some yoga
exercises, but to no avail. I think in all honesty that the whole concept
is wrong, clang/llvm on windows should be treated as if it were vc
(invoking clang-cl) and not as some spin-off of linux-clang, which seems to
amount to try getting a square peg into a round hole. So, we should not
have clang-win, but msvc-clang as a target.

On Mon, 13 Aug 2018 at 06:44, degski <[hidden email]> wrote:

> On Sun, 12 Aug 2018 at 21:21, John Maddock via Boost <
> [hidden email]> wrote:
>
>> There are currently only 4 type_traits tests that fail with clang/llvm
>> on windows - all related to msvc compatibility.
>>
>
> The (type of) errors I refer to is where f.e. std::is_assignable is
> clearly available on compiler/platform but the boost one is reported not
> found, while the obvious std::is_assignable (that should be used) is not
> used. This was in wave, but I'm sure there are more of the same type of
> errors as the above, they probably all just need 1 fix, i.e. it's a class
> of errors.
>
> Wasn't this the/a similar symptom in Regex, it's too long ago cannot
> remember. There the reason was that the detection was too simple, for the
> now more complex situation that has been created (by the arrival of
> Clang/VC STL). Just checking for _MSC_VER no longer does the Job, there
> needs to be a check for __clang__ and/or possibly __GNUC__ depending on
> what one is trying to determine.
>
> I'll build again saving the build output to file and do some diggin'.
>
> degski
> --
> *"If something cannot go on forever, it will stop" - Herbert Stein*
>


--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
degski wrote:

> .\boost/type_traits/has_trivial_move_assign.hpp:49:4: error: no template
> named 'is_assignable'; did you mean 'std::is_assignable'?
>    BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T)

FWIW, this seems to be because BOOST_HAS_TRIVIAL_MOVE_ASSIGN is defined
under Clang as:

#     define BOOST_HAS_TRIVIAL_MOVE_ASSIGN(T) (__is_trivially_assignable(T&,
T&&) && is_assignable<T&, T&&>::value && !::boost::is_volatile<T>::value)

but then the headers for is_assignable or is_volatile aren't included.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
degski wrote:

> I think in all honesty that the whole concept is wrong, clang/llvm on
> windows should be treated as if it were vc (invoking clang-cl) and not as
> some spin-off of linux-clang, which seems to amount to try getting a
> square peg into a round hole. So, we should not have clang-win, but
> msvc-clang as a target.

That's exactly what clang-win does, it's a msvc-lookalike that uses
clang-cl. But it doesn't work. So we use clang-linux, which kind of works,
except for dynamic_cast.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On Mon, 13 Aug 2018 at 15:55, Peter Dimov via Boost <[hidden email]>
wrote:

> degski wrote:
>
> > I think in all honesty that the whole concept is wrong, clang/llvm on
> > windows should be treated as if it were vc (invoking clang-cl) and not
> as
> > some spin-off of linux-clang, which seems to amount to try getting a
> > square peg into a round hole. So, we should not have clang-win, but
> > msvc-clang as a target.
>
> That's exactly what clang-win does, it's a msvc-lookalike that uses
> clang-cl. But it doesn't work. So we use clang-linux, which kind of works,
> except for dynamic_cast.
>

I don't care either way, whatever works. In the end of the day, I'd like
the linux-clang better as it is far clearer what it does or what it doesn't
(and I can look it up consulting the gnu docs), I'm with you here. The
dynamic_cast for some weird reason does not work/link, I saw exactly what
you saw. Some incantation is just simply wrong. On the other hand, what
seems to be lost to everybody (except some clang people) is that clang.exe,
clang++.exe, clang-cpp.exe, clang-cl.exe (and the now removed cl.exe in the
clang distribution) are just copies of the exact same binary, their hash
values confirm this (please check if you doubt what I'm saying). They just
behave differently, because they are named differently, I'm sure anyone
understands that doing that is not rocket-science, you can do this in C. So
passing options to the linux-facade (or the real thing, whatever you'd like
to call it) using the -Xclang prefix in clang-cl really just passes
flags/parameters to the exact same binary, gnu style. So knowing this, my
point is that since vc builds Boost without a problem, clang-cl should
build Boost without a problem as well, while nothing stops anyone from
passing in other options (directly to "the real thing") using the -Xclang
prefix. This is the main reason I don't care, coz I know, it's really the
same thing. I also think that this is the main reason the clang-crew is
un-responsive, because they know the problem is in the incantations.

But, I'm (really) happy we seem be get closer to the problem, at some point
we will solve the conundrum.

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
degski wrote:

> So knowing this, my point is that since vc builds Boost without a problem,
> clang-cl should build Boost without a problem as well,

Sure, the problem with the clang-win.jam toolset is not with Clang, it
(meaning clang-win.jam) just doesn't work for some reason.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On Mon, 13 Aug 2018 at 16:43, Peter Dimov via Boost <[hidden email]>
wrote:

> degski wrote:
>
> > So knowing this, my point is that since vc builds Boost without a
> problem,
> > clang-cl should build Boost without a problem as well,
>
> Sure, the problem with the clang-win.jam toolset is not with Clang, it
> (meaning clang-win.jam) just doesn't work for some reason.
>

Now, let's try find out why it doesn't. I was proposing to approach it from
the other direction, because somehow we seem to have hit a (hitherto)
unknown stumbling block approaching the problem from this (the linux-clang)
end.

degski

--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
On Mon, 13 Aug 2018 at 16:53, degski <[hidden email]> wrote:

> Now, let's try find out why it doesn't. I was proposing to approach it
> from the other direction, because somehow we seem to have hit a (hitherto)
> unknown stumbling block approaching the problem from this (the linux-clang)
> end.
>

Sorry to make this a split post, but it's an addendum to the prior post.

The problem is obviously not in the is_assignable etc, that's just a matter
of sorting (minor bug(s)) that out, walking the code.

degski
--
*"If something cannot go on forever, it will stop" - Herbert Stein*

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: clang-win, again

Boost - Dev mailing list
Hi,

Is it possible to setup and add clang-win (clang-win-7.0) into test
matrix for the 1.69 release?
Several libraries still must be tweaked for it - boost.preprocessor
has build errors, maybe others.

--
Egor Pugin

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1234