Re: [boost] clang-win, again

Subject: Re: [boost] clang-win, again
From: degski (degski_at_[hidden])
Date: 2018-08-13 09:23:13

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_at_std_category
@error_category_at_system@boost@@UEBA_NAEBVerror_code_at_std@@H_at_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 <degski_at_[hidden]> wrote:

> On Sun, 12 Aug 2018 at 21:21, John Maddock via Boost <
> boost_at_[hidden]> 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*