December 2020 - Boost-users - lists.preview.boost.org

boost.python and python3 64 bit
by Cruz, Petagay [USA] 14 Dec '20

14 Dec '20

Does Boost Python support using python 3 64 bit? if yes, how do i build say Boost.Python 1.74? What is the 'b2' command and then the bjam command for the tutorial example? Thank you

1 0

Boost Asio support for OpenSSL 1.1.1
by Gehrs, Volker 14 Dec '20

14 Dec '20

Hi all, we are using boost.asio on windows. Does boost.asio support OpenSSL 1.1.1 in any new version? I could not find a hint in the Revision history of boost.asio. https://www.boost.org/doc/libs/1_75_0/doc/html/boost_asio/history.html Thanks in advance!

2 1

unresolved external symbol __DllMainCRTStartup@12
by Cruz, Petagay [USA] 13 Dec '20

13 Dec '20

I have built boost python. I am trying to use the boost_1_74_0\libs\python\example\tutorial example. I keep getting a fail in the build of the dll: msvc.link.dll bin\msvc-14.0\debug\boost_python.dll LINK : warning LNK4001: no object files specified; libraries used LINK : error LNK2001: unresolved external symbol __DllMainCRTStartup@12 bin\msvc-14.0\debug\boost_python.dll : fatal error LNK1120: 1 unresolved externals call "bin\standalone\msvc\msvc-14.0\msvc-setup.bat" x86 >nul link /NOLOGO /INCREMENTAL:NO /DLL /DEBUG /MACHINE:X86 /MANIFEST:EMBED /subsystem:console /out:"bin\msvc-14.0\debug\boost_python.dll" /IMPLIB:"bin\msvc-14.0\debug\boost_python.lib" @"bin\msvc-14.0\debug\boost_python.dll.rsp" Any advice as to what might be wrong. My Visual Studio 2019 does not have the corelibc.lib. I only find that under 'WinCE' libs, and so not found when I compile msvc 14... thanks

1 0

Where to find a complete boost example using ICL (intel 64bit compiler for windows 10)?
by Mehdi Est 13 Dec '20

13 Dec '20

Hi Everyone, Where can I find a complete boost example using ICL (intel 64bit C/C++ compiler for windows)? I would like to do it in header-only mode. Right now, I am compiling and linking using the below-mentioned flags/libraries. However, when I run the code I seem to experience deadlock because the execution stalls. Please let me know your valuable comments. Regards *Compile Flags* icl -I"C:/Program Files (x86)/IntelSWTools/sw_dev_tools/compilers_and_libraries_2020.2.254/windows/compiler/include" -I/../boost_1_73_0 -I../../../boost_1_73_0 -Qstd=c++0x -Qdiag-error-limit:3 -debug:all -Zi -Z7 -ZI -MDd -D_DEBUG -DBOOST_STACKTRACE_USE_WINDBG -Fo:../../Debug/obj/test.obj -c test.cpp *Link Flags* xilink -LIBPATH:"c:\Program Files (x86)\Windows Kits\10\Lib\10.0.19041.0\um\x64" -out:Debug/test.exe test.obj ole32.lib dbgeng.lib

1 0

[release] Boost 1.75.0
by Marshall Clow 11 Dec '20

11 Dec '20

Release 1.54.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.75.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.75.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Glen Fernandes, Michael Caisse

3 3

Fwd: [Beast] Slow HTTP connect on Windows. Normal?
by Dominique Devienne 11 Dec '20

11 Dec '20

Oops, this was meant for the list of course. --DD ---------- Forwarded message --------- From: Dominique Devienne <ddevienne(a)gmail.com> Date: Fri, Dec 11, 2020 at 6:54 PM Subject: Re: [Boost-users] [Beast] Slow HTTP connect on Windows. Normal? To: Vinnie Falco <vinnie.falco(a)gmail.com> On Wed, Nov 25, 2020 at 7:43 PM Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > On Wed, Nov 25, 2020 at 2:55 AM Dominique Devienne via Boost-users > <boost-users(a)lists.boost.org> wrote: > > Given the high connect time on Windows, I thought I'd try to keep the > connection open on the client, and issue several send-request/read-response > pairs, using the Beast-based (sync) HTTP client, but only the first one > works correctly, the 2nd errors out with: > > > > Error: An established connection was aborted by the software in your > host machine > > This means that the server closed the connection. Are you setting > HTTP/1.1 in the request? For HTTP/1.1 the default is to enable > keep-alive. But for 1.0 the default is to close the connection. > Sorry for the delay. Just getting back to this. Yes, I'm in 1.1, and I verified that the request has Keep-Alive, and I'm (or the example, I don't recall) is setting the same value on the response. > it sounds like your connection is being closed after one request. Beast > definitely supports keep-alive, so this is certainly user error. > Please inspect the request/response messages taking place and post > them on the list unmodified (use a wire sniffer for this if necessary) > if you are still having problems. > Debugging this, I can see that the close arg to on_write is true, despite the Keep-Alive on the response. That response has an empty_body BTW, in case it matters. This route just replies 200 OK or 403 Forbidden, there's no body to return, only the headers matter to the client. The reason why the connection is closed after the 1st request seems to be because of need_eof(). The async server example has something like this in `send()`: template <typename RES> void send(RES&& msg) { // The lifetime of the message has to extend // for the duration of the async operation so // we use a shared_ptr to manage it. auto sp = std::make_shared<RES>(std::move(msg)); // Store a type-erased version of the shared // pointer in the class to keep it alive. res_ = sp; bool need_eof = sp->need_eof(); ctx_.out() << "send: sp->need_eof() = " << need_eof << std::endl; // Write the response http::async_write( stream_, *sp, beast::bind_front_handler( &session::on_write, shared_from_this(), sp->need_eof() ) ); } And `need_eof()` is true indeed. Which thus calls `on_write()` with `bool close = true`, resulting in a `do_close()` instead of waiting for the next request: void on_write( bool close, beast::error_code ec, std::size_t bytes_transferred ) { boost::ignore_unused(bytes_transferred); if (ec) { return; // fail(ec, "write"); } if (close) { // This means we should close the connection, usually because // the response indicated the "Connection: close" semantic. ctx_.out() << "on_write: close()" << std::endl; return do_close(); } // We're done with the response so delete it res_.reset(); // Read another request do_read(); } I stepped into `need_eof()`, and all conditions of the `if` are false, resulting in the `return true` at the end. template<bool isRequest, class Body, class Fields> bool message<isRequest, Body, Fields>:: need_eof(std::false_type) const { // VFALCO Do we need a way to let the caller say "the body is intentionally skipped"? if( this->result() == status::no_content || this->result() == status::not_modified || to_status_class(this->result()) == status_class::informational || has_content_length() || chunked()) return ! keep_alive(); return true; } So is the issue having an empty_body? I'm not supposed to have one on a GET? BTW, I tried commenting out the `do_close()` inside `on_write()`, just to see what happens, and it still doesn't work, with the same error, but an additional delay (timeout?) I think. Here's the response I'm sending: ctx_.out() << "Sending response: 200 OK" << std::endl; http::response<http::empty_body> res{http::status::ok, req_.version()}; res.set(http::field::server, BOOST_BEAST_VERSION_STRING); res.keep_alive(req_.keep_alive()); ctx_.out() << "on_read: res.keep_alive() = " << res.keep_alive() << std::endl; return send(std::move(res)); I'm fairly sure it's user-error, but it's not easy to figure out for a Beast novice like myself. --DD

2 2

Reminder that Outcome v2.2 is to become Boost.Outcome
by Niall Douglas 11 Dec '20

11 Dec '20

After three Boost releases and a year of warning, this is a reminder that Outcome v2.2 is to replace v2.1 as Boost.Outcome. This is a breaking change, all existing Boost.Outcome code shall need to be upgraded as of Boost 1.76 onwards. Changes: https://www.boost.org/doc/libs/1_75_0/libs/outcome/doc/html/changelog/v22.h… Upgrade guide: https://www.boost.org/doc/libs/1_75_0/libs/outcome/doc/html/changelog/upgra… You should see the merge land into boostorg/outcome next few days. It'll take some weeks to upgrade the tutorial and documentation. Niall

1 0

Boost.Beast base64 decode
by Dominique Devienne 11 Dec '20

11 Dec '20

I'm decoding a Java Web Token, composed of 3 separate base64 encoded parts (header.payload.signature). Before I was using Boost.Serialization: using namespace boost::archive::iterators; using It = transform_width<binary_from_base64<std::string::const_iterator>, 8, 6>; std::string tmp(It(std::begin(base64_str)), It(std::end(base64_str))); return boost::algorithm::trim_right_copy_if(tmp, [](char c) { return c == '\0'; }); But since I'm already using Boost.Beast, I thought I'd drop the above dependency, and use this instead: using namespace boost::beast::detail; std::string decoded(base64::decoded_size(base64_str.size()), '\0'); auto rc = base64::decode(decoded.data(), base64_str.data(), base64_str.size()); decoded.resize(rc.first); But turns out some (all?) JWTs do not include the trailing equals that "proper" base64 should have. And in that case, Beast's rc.first does not include the last character, which I can still see in decoded variable prior to the .resize() in the debugger. Here's the payload part: eyJwYXNzd29yZCI6IlAiLCJ1c2VybmFtZSI6IlUifQ What it should decode to: {"password":"P","username":"U"} What Beast's decode yields: {"password":"P","username":"U" Is this on purpose? Could Beast's base64::decode() be changed to be more lenient about the absence of trailing equals from the base64 encoded string? JWT handling seems like a natural fit within the context of Beast, and although this is an implementation detail, it would seem logical for decode() to cope with that, no? Thanks, --DD

3 4

Boost 1.75.0 Release Candidate 1 -- macOS (gcc 10.2.0)
by DV Henkel-Wallace 10 Dec '20

10 Dec '20

> Date: Thu, 3 Dec 2020 06:54:13 -0800 > From: Marshall Clow <mclow.lists(a)gmail.com <mailto:mclow.lists@gmail.com>> > > [release] Boost 1.75.0 Release Candidate 1 > Built fine on macOS 11.0.1 using brew-installed g++-10 ./b2 cxxstd=2a boost.locale.icu=off boost.locale.std=off threading=multi -sNO_COMPRESSION=1 Darwin KA-19.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64 gcc version 10.2.0 (Homebrew GCC 10.2.0) Target: x86_64-apple-darwin19 Lots of deprecated warnings for #pragma GCC diagnostic ignored "-Wdeprecated-copy", use of boost/bind.hpp and boost/detail/iterator.hpp. But otherwise OK. Net: Apple's clang and g++ generated pretty similar warnings. Clang-11 did not.

1 0

Boost 1.75.0 Release Candidate 1 -- macOS (system compiler)
by DV Henkel-Wallace 10 Dec '20

10 Dec '20

> Date: Thu, 3 Dec 2020 06:54:13 -0800 > From: Marshall Clow <mclow.lists(a)gmail.com <mailto:mclow.lists@gmail.com>> > > [release] Boost 1.75.0 Release Candidate 1 > Built fine on macOS 11.0.1 using the system compiler installed with latest Xcode (12.2) ./b2 cxxstd=2a boost.locale.icu=off boost.locale.std=off threading=multi -sNO_COMPRESSION=1 Darwin KA-19.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:11 PDT 2020; root:xnu-7195.50.7~2/RELEASE_X86_64 x86_64 Apple clang version 12.0.0 (clang-1200.0.32.27) Target: x86_64-apple-darwin20.1.0 Lots of deprecated warnings for #pragma GCC diagnostic ignored "-Wdeprecated-copy", use of boost/bind.hpp and boost/detail/iterator.hpp. But otherwise OK.

1 0