August 2015 - Boost - lists.boost.org

Any interest in a M:N green threading library?
by Xu Chen 13 Aug '15

13 Aug '15

Just cleanup some codes I wrote before, there is a M:N green threading library built on top of Boost.Thread and Boost.Coroutine, conceptually it works like goroutines in Go and (once existed) green threads in Rust. With some refinements, it now supports all C++11/14 threading standard, along with some extensions exist in Boost.Thread such as thread_group and chainable futures. It can be integrated with Boost.ASIO, all ASIO async functions can be used as sync ones in green threads, similar to Boost.ASIO/Boost.Coroutine integration. Also it has some facilities to communicate with foreign threads, can by used to integrate with external libs such as database drivers. The code can be found at https://github.com/windoze/boost.green_thread I don't know much about boostbook tools so the documents are kind of crippled, but I'll improve it if needed. Regards, Chen Xu

4 5

Re: [boost] [build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
by Adam Merz 13 Aug '15

13 Aug '15

Andrey Semashev <andrey.semashev <at> gmail.com> writes: > > I created a Connect ticket about it: > > https://connect.microsoft.com/VisualStudio/feedback/details/1651822/incorr ect-mspdb140-dll-version-picked-in-x86-x64-cross-tools-environment > This ticket appears to be set to private; would you mind editing it to public visibility so that we may upvote it? Regards,

5 5

1.59.0 rc3 is now available
by Marshall Clow 12 Aug '15

12 Aug '15

New Release candidate files for 1.59.0 are available at: http://boost.cowic.de/rc/ RC3 should fix the problem with VC14 and MSPDB140.DLL. As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: MD5 (boost_1_59_0_rc3.7z) = 0a2e512844f3e30a6240f8139ee983f3 MD5 (boost_1_59_0_rc3.tar.bz2) = 6aa9a5c6a4ca1016edd0ed1178e3cb87 MD5 (boost_1_59_0_rc3.tar.gz) = 51528a0e3b33d9e10aaa311d9eb451e3 MD5 (boost_1_59_0_rc3.zip) = 08d29a2d85db3ebc8c6fdfa3a1f2b83c Thanks! -- The release managers P.S. Release notes are here: http://www.boost.org/users/history/version_1_59_0.html

3 3

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

[build] Overriding warning level for clang
by Edward Diener 11 Aug '15

11 Aug '15

In my user-config.jam for clang I have added: <warnings>on to the configuration section of the 'using clang' toolset. Nonetheless I still see '-Wall' on the command line when I compile. My other <cxxflags> settings which are part of the toolset are reflected by the command line. Even if I change to <warnings>off in the toolset I still see '-Wall' on the command line. Why is this not working and is there any way I can change the warning level for clang so that it is not 'Wall' on the command line ? The clang compiler is wonderful but with 'Wall' it spews out a boatload of information I normally do not need.

1 0

[build] Problems with VC14 and MSPDB140.DLL (was: [testing][teeks] MSVC-14 errors about MSPDB140.DLL)
by Andrey Semashev 11 Aug '15

11 Aug '15

On Sat, May 23, 2015 at 4:40 PM, Hartmut Kaiser <hartmut.kaiser(a)gmail.com> wrote: > >> All tests for Boost.Log (and I suspect any other built libraries) on MSVC- >> 14 >> are failing because of this error: >> >> LINK : fatal error LNK1101: incorrect MSPDB140.DLL version; recheck >> installation of this product > > My workaround was to edit the 'Path' env variable in one of the temp files > generated by bjam (b2_msvc_14.0_vcvarsall_amd64.cmd in your temp directory) > not to point to the x64 cross compiler, but to the native one. For me this > involved changing > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64_x86 > > To > > C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64 I encountered the same problem with VC14 RTM on my VM. This was a clean install of VC14 RTM, there were no CTPs or RCs installed on this machine. I removed the b2_msvc_14.0_vcvarsall*.cmd scripts and ran b2 with address-model=64 to build my tests so that these scripts are re-created from scratch, so it looks like there is a problem with how these scripts are generated by b2. I found 3 instances of mspdb140.dll on my system in these locations: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64 The last two are for 32 and 64-bit native compilers. The first one, I assume, is for use by IDE. The problem is that the first path is listed in b2_msvc_14.0_vcvarsall_x86_amd64.cmd in the "SET Path=..." line prior to the compiler-specific paths. Removing it from the Path solved the problem. Could Boost.Build be adjusted so that the cmd files are generated correctly in the first place?

9 25

[range] index adaptor with size_t as index_type
by Tobias Loew 10 Aug '15

10 Aug '15

>From version 1.55 to 1.56 the index_type of the index of the range index-adaptor was changed from size_t to ptr_diff which e.g. allows for negativ start values. But this has the side-effect that comparison with other size_t-values (e.g. a call to vector's size()) results in a compiler warning for comparing signed and unsigned values (on MSVC 11: warning C4018: '<' : signed/unsigned mismatch). I'm proposing a specialized version of the index adaptor, where the index_type is size_t and the start index is 0 (zero) and explicit specification of the start-value is not possible. A possible name could be "uindex". comments / critics / pros / cons are welcome Tobias -- View this message in context: http://boost.2283326.n4.nabble.com/range-index-adaptor-with-size-t-as-index… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[python] Help with boost python build
by Andy Thomason 10 Aug '15

10 Aug '15

Hi All, I have had highly variable results with Boost.Python mostly due to linker errors or failures of Python to find DLLs. Python is not great at reporting why it fails, for example not naming failures to load dependent DLLs on Windows which does not make this a joyous experience. I have never managed to get any Boost.Python example - mine or otherwise - working on Windows and have had limited success on Linux. It is little surprise that all the examples on Stackoverflow avoid Bjam for builds. For my genetics library, I have an example that has a single source file and the Jamfile reads thus: python-extension genetics : bindings.cpp : <toolset>gcc:<cxxflags>-std=c++11 ; with: using python : 2.7 ; in ~/boost-config.jam ie. as minimal as possible. This builds well on linux (I am adding a library to the head of modular boost). When I run: python -c "import genetics" with appropriate PYTHONPATH I get a run-time symbol search error: ImportError: <...>/genetics.so: undefined symbol: _ZNK5boost6python7objects21py_function_impl_base9max_arityEv My guess would be that rather than this one symbol, Python is failing to load the shared lib: ~/modular-boost/bin.v2/libs/python/build/gcc-4.8/debug/libboost_python.so.1.59.0 As a postscript, It would be lovely if there were no static or dynamic libraries to link with when compiling with Boost.Python and a unity build would be a nice option as this would bypass linker and runtime related errors. It would probably compile faster in my long experience with such projects. Any help would be welcome. Andy. --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

1 0

[regression tests] Adding regression tests for mingw(-64)/gcc and clang on Windows
by Edward Diener 10 Aug '15

10 Aug '15

I don't know if I am supposed to ask questions about running regression tests in this mailing list or in the Boost testing mailing list, but I will try here first. The Boost testing mailing list seems to be for actual test result problems and the like. For a long time now we have had no regression tests for mingw/gcc or clang targeting gcc on Windows. The only regression tests for Windows are for various releases of VC++. I have limited resources but I have a laptop usually sitting idle, except for occasional travel where I take it with me, and I am set up to run tests on that machine for mingw/gcc and clang on Windows. However mingw/gcc and clang have limitations when running tests in that, both relying on various mingw/gcc implementations, the path to the implementation must be added at the beginning of the PATH before running any of the tests. I have already argued with the mingw-64 people about this necessity but they are adamant that this should be the case even just to compile/link properly ( and have setup their directory structure to enforce it ), and I don't want to waste my breath further with them. Currently I have a batch file that does that for me when running tests for aany particular library, but I don't know how that can be achieved when running the regression tests unless possibly I run regression tests for only a single toolset at a time, and manipulate the PATH accodingly. But that is really time consuming since evidently all of Boost must be downloaded to the run directory each time. Is there an easy solution to this or do I have to look at run.py and try modify it accordingly ( I know Python well ) ? Also I notice on the Boost web site regression test page ( http://www.boost.org/development/running_regression_tests.html ) that the options of the regression tests are somewhat documented but none of the commands are documented. Is there further documentation about the regression test commands anywhere ?

1 0

Build Error VS14 + Intel 15.0 (Update 4, the latest)
by degski 10 Aug '15

10 Aug '15

I have encountered the following error when building boost 1.58 (and 1.59-b1): C:/boost_1_58_0/tools/build/src/tools\intel-win.jam:194: in configure-really from module intel-win error: msvc 14 not supported for intel toolset version 15.0 I'm using the following line to build boost: bjam -a -d+2 --toolset=intel-15.0-vc14 "-sINTEL_PATH=C:\Program Files (x86)\Intel\Composer XE 2015\bin\intel64" cxxflags="/O2 /Quse-intel-optimized-headers /Qstd=c++14 /Qipo /Zc:forScope /Oi /MT /EHsc /Qparallel" "-sINTEL_BASE_MSVC_TOOLSET=vc-14_0" "-sINTEL_VERSION=15" "-sZLIB_SOURCE=%HOME%\zlib-1.2.8" "-sBZIP2_SOURCE=%HOME%\bzip2-1.0.6" variant=release instruction-set=nehalem threading=multi link=static runtime-link=static --stagedir=stage64_static address-model=64 architecture=x86 --without-python --without-mpi --disable-filesystem2 stage > icc_log_stage.log The above worked fine with VS11 and Intel 15.0. The combo (VS14/ICC15) is obviously supported by (MS/Intel), and works fine in the IDE (Community Edition). I confirm the problem with bootstrap.bat, this has been around for a long time, and always had to build the 32bit version first. I ran into it as I have decided to stop building 32-bit. The obvious work-around is to build bjam seperately, not a killer for me, but might be for some. The main issue I report, is though and it would be a shame if the 1.59 release would not allow for that combo, as finally MS have released a free, non-crippled, release of their IDE with (finally, in 2015) full support for C++11... I'm happy to test some things out if necessary, I'm not capable of adressing the issue though...

1 0