|
|
Boost Testing : |
From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2019-06-21 03:35:59
On Thu, Jun 20, 2019 at 10:28 PM Tom Kent <lists_at_[hidden]> wrote:
>
> On Thu, Jun 20, 2019 at 7:15 AM Rene Rivera <grafikrobot_at_[hidden]> wrote:
>
>> Since it's not due to the b2 -j change..
>>
>> On Fri, Jun 14, 2019 at 8:25 AM Tom Kent via Boost-Testing <
>> boost-testing_at_[hidden]> wrote:
>>
>>> For the last few days (Since June 4?) I've been having problems with all
>>> my linux tests running against the develop branch.
>>>
>>> GCC ends with this:
>>>
>>> gcc.compile.c++ ../../bin/common/build/gcc-8/release/process_jam_log.o
>>>
>>> "g++-8" -fPIC -O3 -finline-functions -Wno-inline -Wall
>>> -DBOOST_ALL_NO_LIB=1 -DNDEBUG -D_CRT_SECURE_NO_WARNINGS -
>>> I"/var/boost/run/boost_root" -c -o
>>> "../../bin/common/build/gcc-8/release/process_jam_log.o"
>>> "../../common/build/../src/p
>>> rocess_jam_log.cpp"
>>>
>>> ../../common/build/../src/process_jam_log.cpp: In function
>>> 'std::__cxx11::string {anonymous}::revision(const string&)':
>>> ../../common/build/../src/process_jam_log.cpp:359:16: warning: ignoring
>>> return value of 'int system(const char*)', decla
>>> red with attribute warn_unused_result [-Wunused-result]
>>> std::system("git rev-parse --short=6 HEAD >.short-sha");
>>> ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> ...skipped <p../../bin/testing/build/gcc-8/release>process_jam_log for
>>> lack of <p/var/boost/run/boost_root/bin.v2/libs/f
>>> ilesystem/build/gcc-8/release/link-static/visibility-hidden>libboost_filesystem.a...
>>>
>>>
>>
>> I guess you'd need to find out what it says for trying to build
>> filesystem lib.
>>
>
> Here's what I'm seeing with the filesystem error:
>
> ln -f -s
> "../../libs/detail/include/boost/detail/has_default_constructor.hpp"
> "../../../boost_root/boost/detail/has_
> default_constructor.hpp"
>
> gcc.compile.c++
> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o
>
> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions
> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL
> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG
> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin.
> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o"
> "/var/boost/run/boost_root/libs/file
> system/src/path_traits.cpp"
>
> /var/boost/run/boost_root/libs/filesystem/src/path_traits.cpp:20:10: fatal
> error: boost/filesystem/config.hpp: No such f
> ile or directory
> #include <boost/filesystem/config.hpp>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> ...failed gcc.compile.c++
> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/path_traits.o...
> gcc.compile.c++
> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o
>
> "g++-8" -fvisibility-inlines-hidden -m64 -O3 -finline-functions
> -Wno-inline -Wall -fvisibility=hidden -DBOOST_ALL
> _NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DNDEBUG
> -I"/var/boost/run/boost_root" -c -o "/var/boost/run/boost_root/bin.
> v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o"
> "/var/boost/run/boost_root/libs/file
> system/src/portability.cpp"
>
> /var/boost/run/boost_root/libs/filesystem/src/portability.cpp:20:10: fatal
> error: boost/filesystem/config.hpp: No such f
> ile or directory
> #include <boost/filesystem/config.hpp>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> compilation terminated.
> ...failed gcc.compile.c++
> /var/boost/run/boost_root/bin.v2/libs/filesystem/build/gcc-8/release/link-static/visibility-hidden/portability.o...
>
>
> And several more like that.
>
> However, I'm also suspicious of the timing with the processor change.
>
> Looking back at the last successful builds of develop on linux. I have a
> few from linux/x86_64/docker machines. The last one I saw was building with
> gcc-8 on June 4 around 6:30am CDT. There should have been a successful
> clang run about 5hrs after that (11:30am CDT), and another successful gcc
> around 10hrs after the last one that was actually successful (4:30pm CDT).
>
> This seems like it would correspond to the change to build here:
>
> https://github.com/boostorg/build/commit/451059949d92b52b21f802562a50587f1eeecb82
>
> The other failure I started seeing was only my linux/arm64 machine. This
> doesn't run docker, so might not be affected in the same way. The last
> successful run on there was at 4:50pm CDT on June 4...but it typically
> takes around 9hrs to run so it probably got the pre 451059949 commit.
> However here I can't rule out that it was impacted by a8ab76ef973.
>
> I'm going to try to standup some normal VMs soon and run on them to see if
> they are affected in the same way. It would also be nice if we could try
> backing out the usage of _SC_NPROCESSORS_ONLN and see if that fixes things,
> is that feasible to try for a couple days?
>
Again.. It's not a b2 issue. Specifying the "-jX" option entirely obviates
the changed code. It's almost certainly something else. Places to look
would be in the filesystem lib, or the root "boost" project for changes.
-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net