[boost] clang-win, again
Peter Dimov via Boost
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
Edward Diener via Boost
> 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.
Peter Dimov via Boost
> 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
> ;
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. :-/
Edward Diener via Boost
> 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.
degski via Boost
wrote:
> I agree. It is not very good. In general clang under Windows, whether
> using gcc or vc++ has many problems
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.
>
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*
degski via Boost
wrote:
> Has anyone succeeded in getting clang-cl.exe working under b2?
>
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*
Edward Diener via Boost
> On Sun, 12 Aug 2018 at 04:52, Edward Diener via Boost <bo...@lists.boost.org>
> 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?
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.).
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
degski via Boost
wrote:
> When using clang-cl the vc++ compiler is the backend.
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.
>
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.
>
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.
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.
>
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*
Edward Diener via Boost
> On Sun, 12 Aug 2018 at 14:56, Edward Diener via Boost <bo...@lists.boost.org>
> 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).
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.
>>
>
> 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.
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.
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.
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.
>
> degski
John Maddock via Boost
> 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.
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
degski via Boost
> Boost.config does identify clang as the compiler on Windows correctly,
> whether the frontend is VC++ libraries or mingw(-64) libraries.
>
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.
>
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.
>
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*
degski via Boost
wrote:
> There are currently only 4 type_traits tests that fail with clang/llvm
> on windows - all related to msvc compatibility.
>
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*
degski via Boost
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.
Peter Dimov via Boost
> .\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)
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.
Peter Dimov via Boost
> 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.
clang-cl. But it doesn't work. So we use clang-linux, which kind of works,
except for dynamic_cast.
degski via Boost
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.
>
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*
Peter Dimov via Boost
> So knowing this, my point is that since vc builds Boost without a problem,
> clang-cl should build Boost without a problem as well,
(meaning clang-win.jam) just doesn't work for some reason.
degski via Boost
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.
>
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*
degski via Boost
> 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.
>
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.
Egor Pugin via Boost
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
Edward Diener via Boost
> 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.
>
targeting mingw-64/gcc ?
Egor Pugin via Boost
targeting mingw-64/gcc ?
In other words clang in VC++ compat mode.
--
Egor Pugin
Edward Diener via Boost
>> Do you mean clang on Windows targeting vc++ or clang on Windows
> targeting mingw-64/gcc ?
>
> clang-vc++ aka clang-cl
> In other words clang in VC++ compat mode.
>
>
VC++ compat mode ) :
using msvc ;
using clang : 7.0 : C:/Utilities/LLVM/700/x64/bin/clang++
:
<cxxflags>-Wno-invalid-token-paste
<compileflags>-fmsc-version=1900
<linkflags>--target=x86_64-pc-windows-msvc
<linkflags>-fuse-ld=lld
;
I also add C:\Utilities\LLVM\700\x64\bin first in my PATH and I manually
invoke:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64
before the b2 invocation using toolset=clang-7.0.
It is possible that neither of these extra actions are needed.
Also possible might be to use the -fmsc-version=1915 for vc++14.1 and
invoke the vcvarsall,bat for Microsoft Visual Studio 14.1.
Egor Pugin via Boost
Here - https://www.boost.org/development/tests/develop/developer/summary.html
--
Egor Pugin
Edward Diener via Boost
>> I have this in user-config.jam for clang 7.0 on Windows targeting vc++
>
> Sure, but is it possible to add such config to develop/master tables? :)
> Here - https://www.boost.org/development/tests/develop/developer/summary.html
user-config.jam.
Rene Rivera via Boost
wrote:
> > I have this in user-config.jam for clang 7.0 on Windows targeting vc++
>
> Sure, but is it possible to add such config to develop/master tables? :)
> Here -
> https://www.boost.org/development/tests/develop/developer/summary.html
https://www.boost.org/development/running_regression_tests.html>.
--
-- Rene Rivera
-- Grafik - Don't Assume Anything
-- Robot Dreams - http://robot-dreams.net
degski via Boost
wrote:
> On 10/24/2018 6:33 PM, Egor Pugin via Boost wrote:
> >> Do you mean clang on Windows targeting vc++ or clang on Windows
> > targeting mingw-64/gcc ?
> >
> > clang-vc++ aka clang-cl
> > In other words clang in VC++ compat mode.
> >
> >
>
> I have this in user-config.jam for clang 7.0 on Windows targeting vc++ (
> VC++ compat mode ) :
>
> using msvc ;
>
> using clang : 7.0 : C:/Utilities/LLVM/700/x64/bin/clang++
> :
> <cxxflags>-fmacro-backtrace-limit=0
> <cxxflags>-Wno-invalid-token-paste
> <compileflags>-fmsc-version=1900
> <compileflags>--target=x86_64-pc-windows-msvc
> <linkflags>--target=x86_64-pc-windows-msvc
> <linkflags>-fuse-ld=lld
> ;
>
You are calling clang++.exe, I doubt this invokes a vc-compatible
compiler. From what I have seen is that this approach creates some weird
linux/vc chimaera (all the build paths have some linux reference in it).
I'm not saying [Peter also seems to have this approach] that this [having
compatibility mode on] is required, you're indicated progress in the
PP-realm seem to confirm that.
When Boost-1.69-rc comes out I'll waste a few more hours of my life trying
to compile Boost with Clang, I'll keep you updated. If and when you give it
another try, I would pass on the advice (and more or less request) from
STL, that is to actually use VC-15.9 (yes, that's preview) cleanly
installed, as mixing the old (14.0) and the new, we won't be able to get to
the bottom of it.
I also add C:\Utilities\LLVM\700\x64\bin first in my PATH and I manually
> invoke:
>
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
> amd64
>
> before the b2 invocation using toolset=clang-7.0.
>
> It is possible that neither of these extra actions are needed.
>
Your setup is migrated from VS2015. In a clean install of VS2017,
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" does
not exist.The correct path (for x64 host targeting x64) is "C:\Program
Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat". If you use the
shortcuts in the menu [Windows Key], this problem is solved for you.
You'll need to open a developer command prompt, as, if not, clang (any
clang) will have a hard time locating the VC-STL and other required
libraries in the "windows kits" [8.1 or 10.0]. You could/can also add the
[clang] path afterwards [after opening the build prompt] with 'set
PATH="C:\Utilities\LLVM\700\x64\bin";%PATH%'. Both these actions are
required.
Also possible might be to use the -fmsc-version=1915 for vc++14.1 and
> invoke the vcvarsall,bat for Microsoft Visual Studio 14.1.
>
The version you put is only relevant if Boost actually does something with
the supplied information. In the meanwhile _MSC_VER should give the correct
info.
Last but not least I would like to point out the VS2017 LLVM Compiler
Toolchain Plugin (by Zach Turner). It has (for a while now) been updated
and allows to switch cleanly between VC and Clang, within 1 project,
without having to touch either of the project settings. This plugin now
also allows to use lld as the linker, which opens up the possibility to use
thin-lto from within the IDE (this was formerly not possible). For this to
be useful in respect of Boost, it is necessary to be able to build Boost
with thin-lto enabled as otherwise this cannot work (stuff is vastly
different). Using thin-lto can give massive [yes massive] performance
boosts to your/any code.
To use the LLVM toolchain from Visual Studio after running the installer
above, install the LLVM Compiler Toolchain Visual Studio extension
<https://marketplace.visualstudio.com/items?itemName=LLVMExtensions.llvm-toolchain>
(supports Visual Studio 2017 and later), select a project in Solution
Explorer, open its Property Page (Alt+F7 by default), and in the "General"
section of "Configuration Properties" change "Platform Toolset" to "llvm".
Alternatively, invoke MSBuild with /p:PlatformToolset=llvm to try out the
toolchain without modifying the project files.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Edward Diener via Boost
> On Thu, 25 Oct 2018 at 00:53, Edward Diener via Boost <bo...@lists.boost.org>
> wrote:
>
>> On 10/24/2018 6:33 PM, Egor Pugin via Boost wrote:
>>>> Do you mean clang on Windows targeting vc++ or clang on Windows
>>> targeting mingw-64/gcc ?
>>>
>>> clang-vc++ aka clang-cl
>>> In other words clang in VC++ compat mode.
>>>
>>>
>>
>> I have this in user-config.jam for clang 7.0 on Windows targeting vc++ (
>> VC++ compat mode ) :
>>
>> using msvc ;
>>
>> using clang : 7.0 : C:/Utilities/LLVM/700/x64/bin/clang++
>> :
>> <cxxflags>-fmacro-backtrace-limit=0
>> <cxxflags>-Wno-invalid-token-paste
>> <compileflags>-fmsc-version=1900
>> <compileflags>--target=x86_64-pc-windows-msvc
>> <linkflags>--target=x86_64-pc-windows-msvc
>> <linkflags>-fuse-ld=lld
>> ;
>>
>
> You are calling clang++.exe, I doubt this invokes a vc-compatible
> compiler. From what I have seen is that this approach creates some weird
> linux/vc chimaera (all the build paths have some linux reference in it).
> I'm not saying [Peter also seems to have this approach] that this [having
> compatibility mode on] is required, you're indicated progress in the
> PP-realm seem to confirm that.
on the clang developers mailing list, is that there is absolutely no
difference between clang targeting vc++, which the "--target=" does
above for the compile and the link, and clang-cl. In fact if you look at
a release of LLVM on Windows, which in recent builds defaults to
targeting vc++, you will see that the clang-cl.exe is exactly the same
size as the clang++.exe.
>
> When Boost-1.69-rc comes out I'll waste a few more hours of my life trying
> to compile Boost with Clang, I'll keep you updated. If and when you give it
> another try, I would pass on the advice (and more or less request) from
> STL, that is to actually use VC-15.9 (yes, that's preview) cleanly
> installed, as mixing the old (14.0) and the new, we won't be able to get to
> the bottom of it.
mentioned VS2015. This also means -fmsc-version=1915 for vc++ 14.1.
>
> I also add C:\Utilities\LLVM\700\x64\bin first in my PATH and I manually
>> invoke:
>>
>> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
>> amd64
>>
>> before the b2 invocation using toolset=clang-7.0.
>>
>> It is possible that neither of these extra actions are needed.
>>
>
> Your setup is migrated from VS2015. In a clean install of VS2017,
> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" does
> not exist.The correct path (for x64 host targeting x64) is "C:\Program
> Files (x86)\Microsoft Visual
> Studio\2017\Community\VC\Auxiliary\Build\vcvars64.bat". If you use the
> shortcuts in the menu [Windows Key], this problem is solved for you.
>
> You'll need to open a developer command prompt, as, if not, clang (any
> clang) will have a hard time locating the VC-STL and other required
> libraries in the "windows kits" [8.1 or 10.0]. You could/can also add the
> [clang] path afterwards [after opening the build prompt] with 'set
> PATH="C:\Utilities\LLVM\700\x64\bin";%PATH%'. Both these actions are
> required.
in my original response, I always have the appropriate clang bin
directory first in my PATH.
>
> Also possible might be to use the -fmsc-version=1915 for vc++14.1 and
>> invoke the vcvarsall,bat for Microsoft Visual Studio 14.1.
>>
>
> The version you put is only relevant if Boost actually does something with
> the supplied information. In the meanwhile _MSC_VER should give the correct
> info.
https://clang.llvm.org/docs/MSVCCompatibility.html ). I do not think
Boost Build does anything with it.
>
> degski
Peter Dimov via Boost
> My understanding, from having previously been active asking questions on
> the clang developers mailing list, is that there is absolutely no
> difference between clang targeting vc++, which the "--target=" does above
> for the compile and the link, and clang-cl. In fact if you look at a
> release of LLVM on Windows, which in recent builds defaults to targeting
> vc++, you will see that the clang-cl.exe is exactly the same size as the
> clang++.exe.
line options.
The difference on our side is that clang-cl uses clang-win.jam, derived from
msvc.jam, and clang++ uses clang-linux.jam, derived from gcc.jam. So it's
not the same.
Edward Diener via Boost
> Edward Diener wrote:
>
>> My understanding, from having previously been active asking questions
>> on the clang developers mailing list, is that there is absolutely no
>> difference between clang targeting vc++, which the "--target=" does
>> above for the compile and the link, and clang-cl. In fact if you look
>> at a release of LLVM on Windows, which in recent builds defaults to
>> targeting vc++, you will see that the clang-cl.exe is exactly the same
>> size as the clang++.exe.
>
> The difference on the clang side is only that clang-cl accepts cl
> command line options.
>
> The difference on our side is that clang-cl uses clang-win.jam, derived
> from msvc.jam, and clang++ uses clang-linux.jam, derived from gcc.jam.
> So it's not the same.
because I wanted to test clang under Windows and it seemed to work.
Mainly because I am not knowledgeable enough with bjam to "fix"
clang-win.jam and no one else was ever interested in doing so. With that
said using clang on Windows works reasonably well for me without having
to use clang-cl, but whether targeting gcc or vc++ clang on Windows has
remained problematical in the linking phase for nearly every clang
release. I am now trying clang 7.0 to see if it is better.
Egor Pugin via Boost
to use clang-cl
when used in boost.log.
Both for clang-cl and clang++ (v8 from today's trunk).
Tried different options, nothing is helpful enough. I assume errors
are probably with my compiler options/definitions.
Btw, 'clang++-8 -v' shows that it turns on msvc compatibility (which
is detected on system) by default.
--
Egor Pugin
Edward Diener via Boost
>> With that said using clang on Windows works reasonably well for me without having
> to use clang-cl
>
> I'm not building using b2 and see lots of errors related to boost.pp
> when used in boost.log.
> Both for clang-cl and clang++ (v8 from today's trunk).
> Tried different options, nothing is helpful enough. I assume errors
> are probably with my compiler options/definitions.
> Btw, 'clang++-8 -v' shows that it turns on msvc compatibility (which
> is detected on system) by default.
many errors in the past attempting to build clang on Windows, which were
ignored when I mentioned it on the clang developers list, to want to
keep pursuing another attempt.
When I run the preprocessor tests using b2 with my toolset clang-7.0
targeting VC++ I get no errors at all, so I really do not know what you
are seeing or what you are doing to produce "lots of errors". I am
working with the 'develop' branch of Boost Preprocessor.
degski via Boost
wrote:
> The difference on our side is that clang-cl uses clang-win.jam, derived
> from
> msvc.jam, and clang++ uses clang-linux.jam, derived from gcc.jam. So it's
> not the same.
>
Thanks for acknowledging that they are not the same (within the Boost b2
context).
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
degski via Boost
wrote:
> With that
> said using clang on Windows works reasonably well for me without having
> to use clang-cl, but whether targeting gcc or vc++ clang on Windows has
> remained problematical in the linking phase for nearly every clang
> release. I am now trying clang 7.0 to see if it is better.
>
If you want to use Clang, targeting gcc [which I guess means that you are
using MinGW], you should build Clang [clang++] with[in] MinGW and use it
there. What we [or I at least] am talking about is using Clang as a native
windows compiler [a drop-in for cl.exe], please don't keep on mixing up
those very different things [name mangling keeps getting in the way of
mixing "gcc-targets" with "vc-targets"]. If you wouldn't mix things up,
there would not be any linking issues, as out-of-the-box clang-cl will use
link.exe [the vc-linker]. Using lld with clang [beit ++, -cl or just plain
clang] works perfectly fine as well.
Other than the above gcc-targeting I don't see what [for you] comes in the
way of proper correct working linking [it works for the rest of us]. I
doubt clang-7.0 brings any relief in solving your problem, because the
changes in clang are not at that [basic] level, it also always worked fine
with clang-6, clang-5, clang-4, clang-3.9 and clang-3.8 [in respect of the
latter two, the number of ICE's were rather prohibitive for anything over
"Hello world.", though].
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
degski via Boost
wrote:
> I have not attempted to build clang-8.0 under Windows. I ran into too
> many errors in the past attempting to build clang on Windows, which were
> ignored when I mentioned it on the clang developers list, to want to
> keep pursuing another attempt.
>
It has become clear [following discussions on the cfe-dev mailing list]
that vc/msbuild do(es) not scale well [enough] to build Clang/LLVM. The
recommended [and what more or less seems to be the only way] is to use the
combo Ninja/Cmake/VC. There are some spells [see llvm web-site] you could
utter that allows you to bootstrap Clang with VC and then build Clang with
the [that] latest Clang.
When I run the preprocessor tests using b2 with my toolset clang-7.0
> targeting VC++ I get no errors at all, so I really do not know what you
> are seeing or what you are doing to produce "lots of errors". I am
> working with the 'develop' branch of Boost Preprocessor.
>
As far as I read, Edward said there were 2 errors, one of which he thought,
could be ignored.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Edward Diener via Boost
> On Thu, 25 Oct 2018 at 18:42, Edward Diener via Boost <bo...@lists.boost.org>
> wrote:
>
>> With that
>> said using clang on Windows works reasonably well for me without having
>> to use clang-cl, but whether targeting gcc or vc++ clang on Windows has
>> remained problematical in the linking phase for nearly every clang
>> release. I am now trying clang 7.0 to see if it is better.
>>
>
> If you want to use Clang, targeting gcc [which I guess means that you are
> using MinGW], you should build Clang [clang++] with[in] MinGW and use it
> there.
built targeting gcc, not vc++. It was only with later releases that the
default build of clang for Windows targeted vc++. But whatever the
default build of clang for Windows targeted you could always use the
compile/link -target switch to change it at runtime.
> What we [or I at least] am talking about is using Clang as a native
> windows compiler [a drop-in for cl.exe], please don't keep on mixing up
> those very different things [name mangling keeps getting in the way of
> mixing "gcc-targets" with "vc-targets"].
the fact that clang-cl allows vc++ like options, clang-cl and clang
targeting vc++ work exactly the same.
> If you wouldn't mix things up,
> there would not be any linking issues, as out-of-the-box clang-cl will use
> link.exe [the vc-linker]. Using lld with clang [beit ++, -cl or just plain
> clang] works perfectly fine as well.
various libraries for nearly every release of clang. John Maddock also
brought this up in a past thread. If you had a solution for the linking
issues that worked I did not see it.
>
> Other than the above gcc-targeting I don't see what [for you] comes in the
> way of proper correct working linking [it works for the rest of us]. I
> doubt clang-7.0 brings any relief in solving your problem, because the
> changes in clang are not at that [basic] level, it also always worked fine
> with clang-6, clang-5, clang-4, clang-3.9 and clang-3.8 [in respect of the
> latter two, the number of ICE's were rather prohibitive for anything over
> "Hello world.", though].
>
> degski
Edward Diener via Boost
> On Fri, 26 Oct 2018 at 01:37, Edward Diener via Boost <bo...@lists.boost.org>
> wrote:
>
>> I have not attempted to build clang-8.0 under Windows. I ran into too
>> many errors in the past attempting to build clang on Windows, which were
>> ignored when I mentioned it on the clang developers list, to want to
>> keep pursuing another attempt.
>>
>
> It has become clear [following discussions on the cfe-dev mailing list]
> that vc/msbuild do(es) not scale well [enough] to build Clang/LLVM. The
> recommended [and what more or less seems to be the only way] is to use the
> combo Ninja/Cmake/VC. There are some spells [see llvm web-site] you could
> utter that allows you to bootstrap Clang with VC and then build Clang with
> the [that] latest Clang.
the Ninja/CMake/mingw-64/gcc chain to build. Sometimes I was successful
but many times there were errors and my efforts to try to find out what
was wrong on the clang user and developer mailing lists came to nothing.
>
> When I run the preprocessor tests using b2 with my toolset clang-7.0
>> targeting VC++ I get no errors at all, so I really do not know what you
>> are seeing or what you are doing to produce "lots of errors". I am
>> working with the 'develop' branch of Boost Preprocessor.
>>
>
> As far as I read, Edward said there were 2 errors, one of which he thought,
> could be ignored.
14.1 using the new vc++ preprocessor with the /experimental:preprocessor
switch.
>
> degski
degski via Boost
wrote:
> There is no need to try and do that. Earlier releases for Windows were
> built targeting gcc, not vc++. It was only with later releases that the
> default build of clang for Windows targeted vc++.
You seem to continuously miss the point. I don't want to have anything to
do with GCC!
> But whatever the
> default build of clang for Windows targeted you could always use the
> compile/link -target switch to change it at runtime.
>
How does that work with C++-name-mangling?
Aside from the use of different jam files for clang and clang-cl,
Apart from this detail, it's exactly the same, WTF!
> and
> the fact that clang-cl allows vc++ like options, clang-cl and clang
> targeting vc++ work exactly the same.
>
Yes, this is true, the above is the problem.
I have experienced some linking issues when running Boost tests for
> various libraries for nearly every release of clang. John Maddock also
> brought this up in a past thread. If you had a solution for the linking
> issues that worked I did not see it.
>
Until this "targeting gcc" get's clarified, it's all like spaghetti on the
wall. I do not understand what "targeting gcc" even means in this context.
GCC does not work [on Windows] outside MinGW as far as I know, but this
implies everything should be compiled that way [inside MinGW].
> Other than the above gcc-targeting I don't see what [for you] comes in the
> > way of proper correct working linking [it works for the rest of us]. I
> > doubt clang-7.0 brings any relief in solving your problem, because the
> > changes in clang are not at that [basic] level, it also always worked
> fine
> > with clang-6, clang-5, clang-4, clang-3.9 and clang-3.8 [in respect of
> the
> > latter two, the number of ICE's were rather prohibitive for anything over
> > "Hello world.", though].
>
> Again this is your experience but not mine.,
>
Well, I am not 'targeting gcc' and as far as I know this is not something
clang-cl is doing [whatever that means]. FYI, Microsoft is using clang-cl
as a test case for their STL, they also use Boost as a test-case. If there
were problems linking stuff, I'm sure somebody would have noticed at some
point.
In order to get forward at all, we need to:
1. Forget about GCC! It's got nothing to do with GCC.
2. Don't call clang++.exe in the config file, as this invokes the incorrect
[linux] jam.file [as confirmed by Peter].
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
degski via Boost
wrote:
> Not with clang. The errors I mentioned, in anoter thread, were with vc++
> 14.1 using the new vc++ preprocessor with the /experimental:preprocessor
> switch.
>
You're right, got my wires crossed!
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
degski via Boost
wrote:
> I have not attempted to build clang-8.0 under Windows. I ran into too
> many errors in the past attempting to build clang on Windows, which were
> ignored when I mentioned it on the clang developers list, to want to
> keep pursuing another attempt.
>
Is there any particular reason that you cannot use the binaries that are
available for download from llvm.org? You seem to focus on a problem that
has some interest, but that now stops you from seeing the problem(s) there
is(are) with building boost with clang [which binary is doing that seem
rather irrelevant to me].
degski
-
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Edward Diener via Boost
not work for the OP. I have expressed the opinion that I have gotten
clang targeting vc++, which you insist is not clang-cl in any way even
though it uses the vc++ headers and libraries, to mostly work, except
for some linking issues over a number of releases of clang, when testing
Boost libraries.
If you have a setup under Boost using clang-cl and clang-win that works
in your testing of Boost libraries please present that setup in the form
of jamfile code. Otherwise we are discussing this to no purpose. The
latest correspondent asked in this thread for some setup that would work
and I gave to him what works for me best using clang.
>
> degski
degski via Boost
wrote:
> This entire thread was started because using clang-cl with clang-win did
> not work for the OP.
It doesn't.
I have expressed the opinion that I have gotten
> clang targeting vc++, which you insist is not clang-cl in any way even
> though it uses the vc++ headers and libraries, to mostly work, except
> for some linking issues over a number of releases of clang, when testing
> Boost libraries.
>
So, you also say it doesn't work. Peter also pointed out that the wrong
jam-file is used [in the way you set up the config file], which possibly
leads to linker errors further down the line.
If you have a setup under Boost using clang-cl and clang-win that works
> in your testing of Boost libraries please present that setup in the form
> of jamfile code.
If I would have that [something that works], I would post that and be done
with it [I would shut up].
Otherwise we are discussing this to no purpose.
Until it provably works for more than one person, this discussion **is**
useful. I don't have the impression, though, that we are discussing this
problem in the most effective way. You keep on mixing in the issue of not
being able to build Clang/LLVM itself from source, I don't understand what
that has to do with the issue at hand [not being able to build Boost with
Clang].
The latest correspondent asked in this thread for some setup that would
> work
> and I gave to him what works for me best using clang.
>
You're actually saying it doesn't work, you are bringing up linker issues,
but I think there are more issues. But as I say, until you just download a
Clang binary [the windows one:
https://prereleases.llvm.org/win-snapshots/LLVM-8.0.0-r339319-win64.exe or
https://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe] and go on and try
build Boost with Clang, we are all just looking at spaghetti on the wall.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Edward Diener via Boost
>
> You're actually saying it doesn't work, you are bringing up linker issues,
> but I think there are more issues. But as I say, until you just download a
> Clang binary [the windows one:
> https://prereleases.llvm.org/win-snapshots/LLVM-8.0.0-r339319-win64.exe or
> https://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe] and go on and try
> build Boost with Clang, we are all just looking at spaghetti on the wall.
? All of my setups for using clang on Windows have involved downloading
and installing binaries. As others on this thread have expressed there
are problems using clang on Windows to test Boost libraries. I have
given what setup works for me best.
>
> degski
Paul A. Bristow via Boost
I'd also want to use the binary release like https://releases.llvm.org/7.0.0/LLVM-7.0.0-win64.exe, so I think any effort should be directed at that.
We seem to be so near and yet so far. I sense that the jam files are the key.
Paul
degski via Boost
wrote:
> What makes you think I have not downloaded and installed clang binaries?
You are mentioning that you have experienced problems building Clang/LLVM
using GCC and MinGW. Based on that I conclude that that is what you are
doing [call me stupid, no probs] ... and then that makes me think that the
issues you experience are related to you doing that.
All of my setups for using clang on Windows have involved downloading
> and installing binaries. As others on this thread have expressed there
> are problems using clang on Windows to test Boost libraries. I have
> given what setup works for me best.
>
What works best. How do you compare best over better, if things fail?
AFAICS, the only result that matters is the one that works correctly. The
config you posted does [as confirmed by Peter], per design [no criticism],
the wrong thing [you implicitly invoke boost-build linux stuff, what could
possibly go wrong?].
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Edward Diener via Boost
> On Fri, 26 Oct 2018 at 14:57, Edward Diener via Boost <bo...@lists.boost.org>
> wrote:
>
>> What makes you think I have not downloaded and installed clang binaries?
>
>
> You are mentioning that you have experienced problems building Clang/LLVM
> using GCC and MinGW. Based on that I conclude that that is what you are
> doing [call me stupid, no probs] ... and then that makes me think that the
> issues you experience are related to you doing that.
>
> All of my setups for using clang on Windows have involved downloading
>> and installing binaries. As others on this thread have expressed there
>> are problems using clang on Windows to test Boost libraries. I have
>> given what setup works for me best.
>>
>
> What works best. How do you compare best over better, if things fail?
> AFAICS, the only result that matters is the one that works correctly. The
> config you posted does [as confirmed by Peter], per design [no criticism],
> the wrong thing [you implicitly invoke boost-build linux stuff, what could
> possibly go wrong?].
you have clang as the compiler using the vc++ headers and libraries
creating a Windows executable, and when you use clang targeting
mingw-64/gcc it uses the mingw-64/gcc headers and libraries and also
produces a Windows executable. If both are not testing clang on Windows
I do not know what is.
If I, and obviously the OP of this thread, could get clang-cl using
clang-win to work reliably I would suggest using that. But it is not my
experience that the latter works very well. If that setup works for you,
that is fine.
> degski
degski via Boost
wrote:
> Why can't you get it in your head that when you use clang targeting vc++
> you have clang as the compiler using the vc++ headers and libraries
> creating a Windows executable, and when you use clang targeting
> mingw-64/gcc it uses the mingw-64/gcc headers and libraries and also
> produces a Windows executable.
I have no problem having that in my head. I'm only interested in one of
the two, targeting VC++. I'm also convinced that targeting MinGW, involves
compiling Clang/LLVM yourself, against those MinGW/GCC headers. That
compiler should then be used only with MinGW.
If both are not testing clang on Windows
> I do not know what is.
>
I'm not interested in testing Clang in conjunction with MinGW, mostly
because MinGW is not a stable target and by definition lags.
If I, and obviously the OP of this thread, could get clang-cl using
> clang-win to work reliably I would suggest using that.
To do that you should use/do what you suggest IMO, go the linux route. With
this choice you'll be fully relying on whatever the MinGW devs do [or don't
do] and just hope that that will work. Your own experience seems to
demonstrate that this is the wrong path to follow. Going forward, MinGW
will become, IMHO, a thing of the past.
But it is not my experience that the latter works very well. If that setup
> works for you, that is fine.
>
No, I'm not trying to do what you are trying to do. I don't want to be
dealing with MinGW!!! And trying to do that fails. More so nowadays, CMake
plays an ever more important role and makes building stuff that used to be
Linux/GNU only, often trivial. Most of the reasons to use MinGW [in many
cases] have gone away [also due to and helped by better compliance of VC].
What I take away from this is that at least it has more or less become
clear what you are discussing. So in the future we should actively try to
separate these different issues/configs. Making this clear on the cfe-dev
list [when you address an issue] might also help you, although from what
I'm reading supporting what you are doing/trying to do is back-burner stuff.
The question is, what is clang-win.jam supposed to support, in your terms,
"targeting gcc" or "targeting msvc"?
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Peter Dimov via Boost
> I have rued the day I pushed clang-win.jam from someone elses posting
> because I wanted to test clang under Windows and it seemed to work. Mainly
> because I am not knowledgeable enough with bjam to "fix" clang-win.jam and
> no one else was ever interested in doing so.
tools it obviously knows how to find, so that we could call f.ex.
"clang-cl.exe /lib <options>" and have it do the right thing for us.
Unfortunately, it doesn't. It does have /link which can call link.exe for
us, but this only works for shared libraries.
Perhaps we can capture the output of
clang-cl.exe -### foo.obj /link
and extract the path to link.exe from there...
degski via Boost
wrote:
> ... and extract the path to link.exe from there...
You questioned the wisdom [or stupidity] of running the boost build from a
VC developer command prompt before, AFAICR. Well this is one, open a
dev-command-prompt and link.exe is in the path [plus everything else].
But it would in reality be more interesting to use lld, IMO. On the other
hand, I have not a single dll amongst my libs, and this never is a problem,
so again I'm puzzled.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Peter Dimov via Boost
> > ... and extract the path to link.exe from there...
>
> You questioned the wisdom [or stupidity] of running the boost build from a
> VC developer command prompt before, AFAICR. Well this is one, open a
> dev-command-prompt and link.exe is in the path [plus everything else].
dev prompt (the 64 bit one). But that's not very satisfying.
Peter Dimov via Boost
> dev prompt (the 64 bit one). But that's not very satisfying.
using clang-win : : C:/llvm-6.0.1/bin/clang-cl.exe ;
in user-config, or just
using clang-win ;
if clang-cl.exe is in your PATH. This shouldn't need a developer command
prompt.
It won't win any bjam toolset awards, but the old one didn't work and this
does, at least for me, so there's that.
Some libraries get confused when they see clang-win though, we have work to
do. Thread, for instance, thinks that I want to use threadapi=pthread for
some reason instead of threadapi=win32; Log fails with a link error:
object_name.obj : error LNK2019: unresolved external symbol GetUserNameExW
referenced in function "int `public: __cdecl
boost::log::v2_mt_nt6::ipc::object_name::object_name(enum
log::v2_mt_nt6::ipc::object_name::dtor$2::scope,char const *)'::`1'::dtor$2"
(?dtor$2@?0???0object_name@ipc@v2_mt_nt6@log@boost@@QEAA@W4scope@01234@PEBD@Z@4HA)
..\..\bin.v2\libs\log\build\clang-win-6.0.1\debug\threadapi-win32\threading-multi\boost_log-clangw6-mt-d-x64-1_69.dll
: fatal error LNK1120: 1 unresolved externals
degski via Boost
wrote:
> You can try the attached clang-win.jam, with ...
>
Thanks for sharing. As soon as the first rc is out, I'll give it another go!
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Egor Pugin via Boost
See https://pastebin.com/RXih1XyB
---
Also I found the root cause of my issue.
My build system added VC include paths to command line:
"-IC:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.15.26726/include"
"-IC:/Program Files (x86)/Microsoft Visual
Studio/2017/Community/VC/Tools/MSVC/14.15.26726/ATLMFC/include"
If I add these lines, for example, to
bin.v2\libs\log\build\clang-vc14.1-win-cl6\release\address-model-64\link-static\threadapi-win32\threading-multi\syslog_backend.obj.rsp
it does not compile.
Without them, everything is fine.
Seems like some internal clang-cl issue.
--
Egor Pugin
Peter Dimov via Boost
> > You can try the attached clang-win.jam, with
>
> Using your config I got several errors related to .asm files with b2.
toolset.flags clang-win.compile .ASM $(condition) : $(assembler) -nologo ;
and an issue with Context's Jamfile - it tries to use GNU as for clang-win
instead of masm:
https://github.com/boostorg/context/pull/87
If you try the attached clang-win.jam and apply the patch to Context, it
should build.
I still don't handle <address-model>32 properly, will look into that next.
Also, Math's precompiled headers don't seem to work, I get
clang-cl.exe: warning: support for '-Yu' without a corresponding /FI flag
not implemented yet; flag ignored [-Wclang-cl-pch]
clang-cl.exe: warning: argument unused during compilation:
'-Fpbin.v2\libs\math\build\clang-win-6.0.1\release\link-static\threading-multi\pch.pch'
[-Wunused-com
mand-line-argument]
I probably need to figure out a way to disable them.
Steven Watanabe via Boost
On 10/27/2018 07:07 AM, Peter Dimov via Boost wrote:
> Also, Math's precompiled headers don't seem to work, I get
>
> clang-cl.exe: warning: support for '-Yu' without a corresponding /FI
> flag not implemented yet; flag ignored [-Wclang-cl-pch]
>
> clang-cl.exe: warning: argument unused during compilation:
> '-Fpbin.v2\libs\math\build\clang-win-6.0.1\release\link-static\threading-multi\pch.pch'
> [-Wunused-com
> mand-line-argument]
>
> I probably need to figure out a way to disable them.
>
from toolset.inherit-generators.
In Christ,
Steven Watanabe
Peter Dimov via Boost
> On 10/27/2018 07:07 AM, Peter Dimov via Boost wrote:
> It should be enough to exclude the pch generators from
> toolset.inherit-generators.
Latest iteration attached. This handles 32/64 properly, disables precompiled
headers, and builds everything for me without errors (assuming that the
Context patch is applied.)
Egor Pugin via Boost
For some reason nothing is changed for .asm files.
Still those errors like ml/ml64 were not found or selected.
Should I call vcvars32/64 before building?
Now I invoke on fresh cmd with updated clang-win.jam:
b2 toolset=clang-win
--
Egor Pugin
Peter Dimov via Boost
> > Latest iteration attached.
>
> For some reason nothing is changed for .asm files.
https://github.com/boostorg/context/pull/87
to Boost.Context, or switch it to the pr/clang-win/masm branch:
cd libs/context
git checkout pr/clang-win-masm
There's nothing I can do from the clang-win.jam side to fix it. :-)
Egor Pugin via Boost
Asm files were changed in the output, but ml executable still missing.
--
Egor Pugin
Peter Dimov via Boost
> > You need to apply the patch
>
> I applied it before my previous post.
> Asm files were changed in the output, but ml executable still missing.
b2 --debug-clang-configuration --with-context
say?
Egor Pugin via Boost
Peter Dimov via Boost
> https://pastebin.com/kdthbdWY
clang-win.compile.asm bin.v2\libs\context\build\clang-vc14.1-win-cl6\...
The `clang-vc14.1-win-cl6` part indicates to me that you have something in
your user-config.
When I issue
b2 --debug-clang-configuration --with-context toolset=clang-win
without having any `using clang` statements in user-config, I get diagnostic
output of the form...
well, to be frank, I got
C:/boost-git/develop/tools/build/src/tools\clang-win.jam:52: in
clang-win.init from module clang-win
error: Please set <compatibility> property for visual studio version!
because I had reset my clang-win.jam to the develop one, but when I switch
tools/build to pr/fix-clang-win, I get...
well, I got
C:/boost-git/develop/tools/build/src/tools\clang-win.jam:71: in
clang-win.init from module clang-win
error: Cannot configure toolset clang-win: no 'clang-cl.exe' command
found or given
because I forgot to add llvm to the PATH, but when I do that, I get (and
this time it will work, I promise)
notice: [clang-win] configuring 'clang-cl.exe' version '6.0.1'
notice: [clang-win] 32: using assembler '"C:\\Program Files (x86)\\Microsoft
Vis
ual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x86\ml.
exe"'
notice: [clang-win] 32: using archiver '"C:\\Program Files (x86)\\Microsoft
Visu
al
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\HostX86\x86\link.e
xe" /lib'
notice: [clang-win] 32: using SDK path 'C:\\Program Files (x86)\\Windows
Kits\\1
0\\bin\x86'
notice: [clang-win] 32: using manifest-tool '"C:\\Program Files
(x86)\\Windows K
its\\10\\bin\x86\mt.exe"'
notice: [clang-win] 32: using resource-compiler '"C:\\Program Files
(x86)\\Windo
ws Kits\\10\\bin\x86\rc.exe"'
notice: [clang-win] 32: using mc-compiler '"C:\\Program Files (x86)\\Windows
Kit
s\\10\\bin\x86\mc.exe"'
notice: [clang-win] 32: using idl-compiler '"C:\\Program Files
(x86)\\Windows Ki
ts\\10\\bin\x86\midl.exe"'
notice: [clang-win] 64: using assembler '"C:\\Program Files (x86)\\Microsoft
Vis
ual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\ml6
4.exe"'
notice: [clang-win] 64: using archiver '"C:\\Program Files (x86)\\Microsoft
Visu
al
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\\lin
k.exe" /lib'
notice: [clang-win] 64: using SDK path 'C:\\Program Files (x86)\\Windows
Kits\\1
0\\bin\x64'
notice: [clang-win] 64: using manifest-tool '"C:\\Program Files
(x86)\\Windows K
its\\10\\bin\x64\mt.exe"'
notice: [clang-win] 64: using resource-compiler '"C:\\Program Files
(x86)\\Windo
ws Kits\\10\\bin\x64\rc.exe"'
notice: [clang-win] 64: using mc-compiler '"C:\\Program Files (x86)\\Windows
Kit
s\\10\\bin\x64\mc.exe"'
notice: [clang-win] 64: using idl-compiler '"C:\\Program Files
(x86)\\Windows Ki
ts\\10\\bin\x64\midl.exe"'
Performing configuration checks
and so on, with the directory of the intermediate files being
clang-win-6.0.1, which matches my LLVM version.
Edward Diener via Boost
Boost Build's 'develop' branch. Thanks, Peter, for working on this !
This will make it easier for others who participated on this thread to
try his update.
Oliver Kowalke via Boost
Am Di., 30. Okt. 2018, 01:01 hat Edward Diener via Boost <
bo...@lists.boost.org> geschrieben:
degski via Boost
wrote:
> I have merged Peter's fix for clang-win.jam, from a PR he created, to
> Boost Build's 'develop' branch. Thanks, Peter, for working on this !
> This will make it easier for others who participated on this thread to
> try his update.
>
I'm building from the dev-head. I get this:
clang-win.archive
c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib
if exist
"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib"
DEL
"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib"
C:\Program Files\LLVM\bin\llvm-ar.exe /nologo
/out:"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib"
@"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib.rsp"
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
So this C:\Program Files\LLVM\bin\llvm-ar.exe does not seem to work, and
gets cut down to 'C:\Program', i.e. it's not properly quoted. This would
confirm what Peter said, that he cannot build static libs. I do seem to get
all the .obj files (i.e. stuff compiles), but it's messy.
Just for information. On Windows, for a while [approx. 20+ years] there is
the xcopy command. It [can] copies whole file-trees [with 1 command], and
can do so selectively (f.e. only copy when the source file is newer than
the destination file), it is also possible to make xcopy shut up about what
it copies. It would be helpful to stop doing all the unnecessary copying
[in the build] and also stop all the useless output, which [the output]
makes it extremely hard to see what's actually going on.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Peter Dimov via Boost
> I'm building from the dev-head. I get this:
>
> clang-win.archive
> c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib
>
> if exist
> "c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib"
> DEL
> "c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib"
> C:\Program Files\LLVM\bin\llvm-ar.exe /nologo
> /out:"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib"
> @"c:\boost-build\boost\bin.v2\libs\thread\build\clng-win-8.0.0\dbg\adrs-mdl-64\lnk-sttc\thrdp-wn32\thrd-mlt\libboost_thread-clangw8-mt-d-x64-1_69.lib.rsp"
>
> 'C:\Program' is not recognized as an internal or external command,
> operable program or batch file.
>
> So this C:\Program Files\LLVM\bin\llvm-ar.exe does not seem to work, and
> gets cut down to 'C:\Program', i.e. it's not properly quoted. This would
> confirm what Peter said, that he cannot build static libs.
What do you have in user-config? I don't think that llvm-ar.exe can get
autodetected.
What does --debug-clang-configuration say?
degski via Boost
wrote:
I have this project-config.jam
using clang-win : : :
<compatibility>vc14
<compileflags>-fmsc-version=1915
<ranlib>"C:\\Program Files\\LLVM\\bin\\llvm-ranlib.exe"
<archiver>"C:\\Program Files\\LLVM\\bin\\llvm-ar.exe"
<rc>"C:\\Program Files (x86)\\Windows
Kits\\10\\bin\\10.0.17763.0\\x64\\rc.exe"
<compileflags>--target=x86_64-pc-win32
<linkflags>--target=x86_64-pc-win32
<linkflags>-fuse-ld=lld
<linkflags>-flto=thin
<architecture>x86
<address-model>64
<link>static
<runtime-link>static
;
and then I make this call:
b2 -a -d+2 -j2 -o%HOME%\clang_log_debug.log
"-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6"
variant=debug threading=multi --abbreviate-paths --prefix=%PREFIX%
--build-dir=c:\boost-build --without-python --without-mpi --without-math
--disable-filesystem2 install
In my setup, Clang/LLVM (/bin) is in my PATH.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Peter Dimov via Boost
> I have this project-config.jam
>
> using clang-win : : :
>
> <compatibility>vc14
> <compileflags>-fmsc-version=1915
> <ranlib>"C:\\Program Files\\LLVM\\bin\\llvm-ranlib.exe"
> <archiver>"C:\\Program Files\\LLVM\\bin\\llvm-ar.exe"
> <rc>"C:\\Program Files (x86)\\Windows
> Kits\\10\\bin\\10.0.17763.0\\x64\\rc.exe"
> <compileflags>--target=x86_64-pc-win32
> <linkflags>--target=x86_64-pc-win32
> <linkflags>-fuse-ld=lld
> <linkflags>-flto=thin
> <architecture>x86
> <address-model>64
> <link>static
> <runtime-link>static
> ;
nothing at all.
The quoting issue is interesting; I do quote the command, which quoting I
left from the previous clang-win.jam, but I don't quote the options such as
<archiver>, because msvc.jam doesn't either. It probably needs to be
consistent, but I'm not sure which way consistent.
degski via Boost
wrote:
> What does --debug-clang-configuration say?
>
Well, lots, coz it's doing a build, but just from the beginning:
C:\boost>b2 --debug-clang-configuration
notice: [clang-win] configuring 'clang-cl.exe' version '8.0.0'
notice: [clang-win] 32: using assembler '"C:\\Program Files
(x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x86\ml.exe"'
notice: [clang-win] 32: using archiver 'C:\Program
Files\LLVM\bin\llvm-ar.exe' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< no
quotes
notice: [clang-win] 32: using manifest-tool 'mt.exe'
notice: [clang-win] 32: using resource-compiler 'rc.exe'
notice: [clang-win] 32: using mc-compiler 'mc.exe'
notice: [clang-win] 32: using idl-compiler 'midl.exe'
notice: [clang-win] 64: using assembler '"C:\\Program Files
(x86)\\Microsoft Visual
Studio\\2017\\Community\\VC\\Tools\\MSVC\\14.15.26726\\bin\\HostX64\\x64\ml64.exe"'
notice: [clang-win] 64: using archiver 'C:\Program
Files\LLVM\bin\llvm-ar.exe' <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< no quotes
notice: [clang-win] 64: using manifest-tool 'mt.exe'
notice: [clang-win] 64: using resource-compiler 'rc.exe'
notice: [clang-win] 64: using mc-compiler 'mc.exe'
notice: [clang-win] 64: using idl-compiler 'midl.exe'
Performing configuration checks
- default address-model : 64-bit (cached)
- default architecture : x86 (cached)
Building the Boost C++ Libraries.
- symlinks supported : yes (cached)
- C++11 mutex : yes (cached)
- Boost.Config Feature Check: cxx11_auto_declarations : yes (cached)
- Boost.Config Feature Check: cxx11_constexpr : yes (cached)
- Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached)
- Boost.Config Feature Check: cxx11_final : yes (cached)
- Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached)
- Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached)
- Boost.Config Feature Check: cxx11_lambdas : yes (cached)
- Boost.Config Feature Check: cxx11_noexcept : yes (cached)
- Boost.Config Feature Check: cxx11_nullptr : yes (cached)
- Boost.Config Feature Check: cxx11_rvalue_references : yes (cached)
- Boost.Config Feature Check: cxx11_template_aliases : yes (cached)
- Boost.Config Feature Check: cxx11_thread_local : yes (cached)
- Boost.Config Feature Check: cxx11_variadic_templates : yes (cached)
- has_icu builds : no (cached)
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam.
note: to suppress this message, pass "--without-graph_parallel" to bjam.
- zlib : no (cached)
- bzip2 : no (cached)
- lzma : no (cached)
- zstd : no (cached)
- iconv (libc) : no (cached)
- iconv (separate) : no (cached)
- icu : no (cached)
- icu (lib64) : no (cached)
- native-atomic-int32-supported : no (cached)
- message-compiler : yes (cached)
- native-syslog-supported : no (cached)
- pthread-supports-robust-mutexes : no (cached)
- compiler-supports-ssse3 : yes (cached)
- compiler-supports-avx2 : yes (cached)
- gcc visibility : yes (cached)
- long double support : yes (cached)
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.
- libbacktrace builds : no (cached)
- addr2line builds : no (cached)
- WinDbg builds : no (cached)
- WinDbgCached builds : no (cached)
- BOOST_COMP_GNUC >= 4.3.0 : no (cached)
- zlib : no (cached)
- bzip2 : no (cached)
- lzma : no (cached)
- zstd : no (cached)
- C++11 mutex : yes (cached)
- Boost.Config Feature Check: cxx11_auto_declarations : yes (cached)
- Boost.Config Feature Check: cxx11_constexpr : yes (cached)
- Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached)
- Boost.Config Feature Check: cxx11_final : yes (cached)
- Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached)
- Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached)
- Boost.Config Feature Check: cxx11_lambdas : yes (cached)
- Boost.Config Feature Check: cxx11_noexcept : yes (cached)
- Boost.Config Feature Check: cxx11_nullptr : yes (cached)
- Boost.Config Feature Check: cxx11_rvalue_references : yes (cached)
- Boost.Config Feature Check: cxx11_template_aliases : yes (cached)
- Boost.Config Feature Check: cxx11_thread_local : yes (cached)
- Boost.Config Feature Check: cxx11_variadic_templates : yes (cached)
- has_icu builds : no (cached)
- zlib : no (cached)
- bzip2 : no (cached)
- lzma : no (cached)
- zstd : no (cached)
- iconv (libc) : no (cached)
- iconv (separate) : no (cached)
- icu : no (cached)
- icu (lib64) : no (cached)
- native-atomic-int32-supported : no (cached)
- message-compiler : yes (cached)
- native-syslog-supported : no (cached)
- pthread-supports-robust-mutexes : no (cached)
- compiler-supports-ssse3 : yes (cached)
- compiler-supports-avx2 : yes (cached)
- gcc visibility : yes (cached)
- long double support : yes (cached)
- libbacktrace builds : no (cached)
- addr2line builds : no (cached)
- WinDbg builds : no (cached)
- WinDbgCached builds : no (cached)
- BOOST_COMP_GNUC >= 4.3.0 : no (cached)
- zlib : no (cached)
- bzip2 : no (cached)
- lzma : no (cached)
- zstd : no (cached)
Component configuration:
- atomic : building
- chrono : building
- container : building
- context : building
- contract : building
- coroutine : building
- date_time : building
- exception : building
- fiber : building
- filesystem : building
- graph : building
- graph_parallel : building
- iostreams : building
- locale : building
- log : building
- math : building
- mpi : building
- nowide : building
- program_options : building
- python : building
- random : building
- regex : building
- serialization : building
- stacktrace : building
- sync : building
- system : building
- test : building
- thread : building
- timer : building
- type_erasure : building
- wave : building
...patience...
...patience...
...patience...
...patience...
...patience...
...patience...
...found 33480 targets...
...updating 2361 targets...
We're cross-posting now (saw you answered, while writing).
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
degski via Boost
wrote:
> Yeah, you'll need to delete all that. Either just `using clang-win ;` or
> nothing at all.
>
So where to add any options/commands? On the command line?
The quoting issue is interesting; I do quote the command, which quoting I
> left from the previous clang-win.jam, but I don't quote the options such
> as
> <archiver>, because msvc.jam doesn't either. It probably needs to be
> consistent, but I'm not sure which way consistent.
>
Not only is it not quoted, but the escape is gone as well.
If you are able to build all, correctly, could you please post a recipe,
like do this, do that... I'm starting from the develop-head of a few hours
ago, those (your) PR's are in there. I have the latest VC-15.8.8, I'm on
Win10-1809, including the CRT's.
I would like to build static libs, x64, statically linked with/instrumented
for lld and thin-lto, optimized for broadwell (release and debug).
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Peter Dimov via Boost
I can, but I don't use lld or thin-lto.
> I would like to build static libs, x64, statically linked
> with/instrumented for lld and thin-lto, optimized for broadwell (release
> and debug).
cl.exe-compatible driver, and you'll be trying to use decidedly non-cl.exe
things.
But you can try with your config, I suppose. Use
<archiver>"\"C:\\Program Files\\LLVM\\llvm-ar.exe\""
for now, to manually quote it.
--target, <architecture>, <address-model> shouldn't be needed. <ranlib> is a
gcc-style option, it's never worked with clang-win, only with clang-linux.
<rc> too.
degski via Boost
wrote:
> > If you are able to build all, correctly, ...
>
> I can, but I don't use lld or thin-lto.
>
You should try ThinLTO
<http://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html>,
it can generate wildly better binary code [and Clang/llvm does not
implement VC's LTO]. For being able to benefit, you'll need lld
<https://clang.llvm.org/docs/ThinLTO.html>, though.
That's a bit odd because clang-win is basically clang-cl.exe, which is the
> cl.exe-compatible driver, and you'll be trying to use decidedly non-cl.exe
> things.
>
As you can spot in the docs <https://clang.llvm.org/docs/ThinLTO.html> ,
clang-cl is specifically mentioned in relation to ThinLTO and lld.
But you can try with your config, I suppose. Use
>
> <archiver>"\"C:\\Program Files\\LLVM\\llvm-ar.exe\""
>
> for now, to manually quote it.
>
I'll try that.
--target, <architecture>, <address-model> shouldn't be needed.
>
How do I get 64-bit binaries then?
As Edward pointed out at length, clang, clang-cl and clang++ are the same
binary. You can pass gcc-like options "through" clang-cl, using the -Xclang
prefix, f.e. '-Xclang -fforce-enable-int128', will make gcc-style 128-bit
ints available on Windows (targeting VC, to keep the ED-speak).
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
degski via Boost
wrote:
> But you can try with your config, I suppose. Use
>
> <archiver>"\"C:\\Program Files\\LLVM\\llvm-ar.exe\""
>
> for now, to manually quote it.
>
The correct path is <archiver>"\"C:\\Program
Files\\LLVM\\bin\\llvm-ar.exe\"", but indeed, then it still doesn't work,
without it, it does.
<rc> too.
>
rc, the resource compiler, are you sure that's not a valid Windows-thing?
I did get to compile some 35+ libs, that excludes mpi and python. I did not
yet pass the -flto=thin flag, that seems to cause trouble.
Some random warnings:
...
clang-cl: warning: unknown argument ignored in clang-cl: '-pedantic'
[-Wunknown-argument]
...
In file included from libs\container\src\alloc_lib.c:24:
In file included from libs\container\src/dlmalloc_ext_2_8_6.c:36:
libs\container\src/dlmalloc_2_8_6.c(1878,47): warning: incompatible
pointer types passing 'int *' to parameter of type 'volatile long *'
[-Wincompatible-pointer-types]
...
In file included from libs\contract\src\contract.cpp:11:
In file included from .\boost/contract/detail/inlined.hpp:11:
In file included from .\boost/contract/detail/inlined/core/exception.hpp:18:
In file included from .\boost/exception/diagnostic_information.hpp:11:
.\boost/exception/info.hpp(85,67): warning: expression with side effects
will be evaluated despite being used as an operand to 'typeid'
[-Wpotentially-evaluated-expression]
BOOST_ASSERT(
*BOOST_EXCEPTION_DYNAMIC_TYPEID(*p).type_==*ti.type_ );
^
.\boost/exception/info.hpp(134,21): warning: delete called on non-final
'boost::exception_detail::error_info_container_impl' that has virtual
functions but non-virtual destructor [-Wdelete-non-virtual-dtor]
delete this;
^
...
clang-cl: warning: unknown argument ignored in clang-cl:
'-ftemplate-depth-255' [-Wunknown-argument]
clang-cl: warning: unknown argument ignored in clang-cl:
'-fvisibility=hidden' [-Wunknown-argument]
clang-cl: warning: unknown argument ignored in clang-cl:
'-fvisibility-inlines-hidden' [-Wunknown-argument]
So, overall, progress has been made, great!
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________
Peter Dimov via Boost
> > <rc> too.
>
> rc, the resource compiler, are you sure that's not a valid Windows-thing?
https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L73
and so is <ranlib>:
https://github.com/boostorg/build/blob/develop/src/tools/gcc.jam#L66
So, these are what clang-linux.jam uses, as it's gcc based.
Whereas the msvc.jam name for this option is <resource-compiler>:
https://github.com/boostorg/build/blob/develop/src/tools/msvc.jam#L109
and, since clang-win is msvc-based, I've used the latter.
Your whole configuration was for clang-linux, but you tried to use it with
clang-win.
> How do I get 64-bit binaries then?
degski via Boost
wrote:
> Whereas the msvc.jam name for this option is <resource-compiler>:
>
I was [by my mind] led into believing "rc" stood for resource compiler. .rc
is also the file-name-ending one would give to resource files.
Your whole configuration was for clang-linux, but you tried to use it with
> clang-win.
>
Yes, too much trial-and-error, not always productive, but we are getting
there.
address-model=64 on the command line, as with msvc.
>
In the meanwhile, I figured that out as well: architecture, address-model
and instruction-set, all on the command line.
degski
--
*“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________