- Boost - lists.boost.org

bootstrap.bat broken for MinGW since 1.55
by Björn Pollex 07 Dec '13

07 Dec '13

I have just tried to bootstrap Boost 1.55 for use with 32 bit MinGW on Windows 7. Here is what I get: C:\Users\pollexb\git_repositories\modular-boost>bootstrap.bat Building Boost.Build engine '"VCVARS32.BAT"' is not recognized as an internal or external command operable program or batch file. '"VCVARS32.BAT"' is not recognized as an internal or external command operable program or batch file. '"VCVARS32.BAT"' is not recognized as an internal or external command operable program or batch file. '"VCVARS32.BAT"' is not recognized as an internal or external command operable program or batch file. 'cl' is not recognized as an internal or external command, operable program or batch file. Failed to build Boost.Build engine. Please consult bootstrap.log for furter diagnostics. You can try to obtain a prebuilt binary from http://sf.net/project/showfiles.php?group_id=7586&package_id=72941 Also, you can file an issue at http://svn.boost.org Please attach bootstrap.log in that case. The log file has the following contents: ### ### Using 'msvc' toolset. ### C:\Users\pollexb\git_repositories\modular-boost\tools\build\v2\engine>if exist bootstrap rd /S /Q bootstrap C:\Users\pollexb\git_repositories\modular-boost\tools\build\v2\engine>md bootstrap C:\Users\pollexb\git_repositories\modular-boost\tools\build\v2\engine>cl /nologo /GZ /Zi /MLd /Fobootstrap/ /Fdbootstrap/ -DNT -DYYDEBUG kernel32.lib advapi32.lib user32.lib /Febootstrap\jam0 command.c compile.c constants.c debug.c execcmd.c execnt.c filent.c frames.c function.c glob.c hash.c hdrmacro.c headers.c jam.c jambase.c jamgram.c lists.c make.c make1.c object.c option.c output.c parse.c pathnt.c pathsys.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c md5.c class.c cwd.c w32_getreg.c native.c modules/set.c modules/path.c modules/regex.c modules/property-set.c modules/sequence.c modules/order.c For some reason it simply ignores the option I pass in and tries to use msvc instead. I recall that there was some discussion about boostrap.sh prior to the 1.55 release, but could not find anything there that affected bootstrap.bat. I have tried with the source archive downloaded from Sourceforge, and with the master branch from Github, both times I get the same error. It works fine with Boost 1.54. Does anyone know what change could have caused this? Regards, Björn Pollex

7 11

[type_erasure] Using BOOST_TYPE_ERASURE_MEMBER
by Andrzej Krzemienski 06 Dec '13

06 Dec '13

Hi, I need some help with using BOOST_TYPE_ERASURE_MEMBER. The example in the tutorial works as described. But the interface binds to object by reference. But if I change it to bind by value, I get a compile-time error. BOOST_TYPE_ERASURE_MEMBER((has_push_back), push_back, 1) void append_many(any<has_push_back<void(int)>> container) { for(int i = 0; i < 10; ++i) container.push_back(i);} How can I fix it? I do want to bind by value. Regards, &rzej

1 1

[git] automatic ticket closing
by Joaquin M Lopez Munoz 06 Dec '13

06 Dec '13

Trac has this nice feature by which one can close a ticket merely by indicating its #number in the associated fix commit message. Is there anything similar for Git? Plans to add it to our Trac environment? Thank you, Joaquín M López Muñoz Telefónica Digital

11 14

[assign] Boost.Assign is incompatible with std::initializer_list
by Stephan T. Lavavej 06 Dec '13

06 Dec '13

Hi Boost devs, Our testing has discovered an apparent incompatibility between Boost.Assign and std::initializer_list. I'm using Boost 1.55.0 and a build somewhat newer than VC 2013 RTM (I could check with RTM if someone really wanted me to): C:\Temp>type meow.cpp #include <set> #include <boost/assign/list_of.hpp> int main() { std::set<int> s; s = boost::assign::list_of(11)(22)(33); } C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp /I boost_1_55_0 meow.cpp meow.cpp(7) : error C2593: 'operator =' is ambiguous E:\binaries\x86ret\inc\set(180): could be 'std::set<int,std::less<_Kty>,std::allocator<_Kty>> &std::set<_Kty,std::less<_Kty>,std::allocator<_Kty>>::operator =(std::initializer_list<int>)' with [ _Kty=int ] E:\binaries\x86ret\inc\set(139): or 'std::set<int,std::less<_Kty>,std::allocator<_Kty>> &std::set<_Kty,std::less<_Kty>,std::allocator<_Kty>>::operator =(std::set<_Kty,std::less<_Kty>,std::allocator<_Kty>> &&)' with [ _Kty=int ] E:\binaries\x86ret\inc\set(123): or 'std::set<int,std::less<_Kty>,std::allocator<_Kty>> &std::set<_Kty,std::less<_Kty>,std::allocator<_Kty>>::operator =(const std::set<_Kty,std::less<_Kty>,std::allocator<_Kty>> &)' with [ _Kty=int ] while trying to match the argument list '(std::set<int,std::less<_Kty>,std::allocator<_Kty>>, boost::assign_detail::generic_list<int>)' with [ _Kty=int ] Note that this repros with std::set and not with std::vector because of a bizarre compiler bug (it's sensitive to the order in which operator=() overloads are declared, and std::set's order is different from std::vector's). Although we've got that compiler bug (and another one affecting overload resolution for braced-init-lists which shouldn't be relevant here), I believe this compiler error is correct, and Boost.Assign is buggy. http://www.boost.org/doc/libs/1_55_0/libs/assign/doc/index.html#list_of_ref depicts an unconstrained "operator Container()", which worked until the containers gained op=() for initializer_list. Is this a known issue? (It should repro for other platforms, although I haven't checked.) Should this conversion operator be constrained so it can't be instantiated for initializer_list? Thanks, STL

2 2

[git] Open for development?
by Andrey Semashev 05 Dec '13

05 Dec '13

Hi, Sorry if I missed the announcement, but is git open for development? I.e. won't my commits disappear at some point?

3 2

Pushing develop changes for a library
by Edward Diener 05 Dec '13

05 Dec '13

I would like to push some develop changes for a Boost library for which I have write access using git. Do I have to notify anyone controlling the Boost superproject about this ?

3 2

[git] regression tests?
by Oliver Kowalke 05 Dec '13

05 Dec '13

Hi, do the regression tests (trunk/release -> develop/master) source the git-repo boostorg? Oliver

2 1

[git] regression testing
by Joaquin M Lopez Munoz 05 Dec '13

05 Dec '13

Hi, Congrats on the recent Git switchover. Two questions: * Are regression test scripts yet adapted to the new repository? * For SVN, test columns mark the latest commit the tests are done against. How will we do with Git? Looks like commits are identified by 40-digit numbers, which are considerably harder to visually track than nice consecutive SVN changeset numbers. Joaquín M López Muñoz Telefónica Digital

3 3

Git hardlinks, and developing
by John Maddock 05 Dec '13

05 Dec '13

OK so I've just been hit by my first Git SNAFU. 1) I checked out modular Boost as per https://svn.boost.org/trac/boost/wiki/TryModBoost 2) Changed libs/multiprecision to the develop branch also as per https://svn.boost.org/trac/boost/wiki/TryModBoost 3) Added some pending changes from the old SVN Trunk that I didn't commit before the changeover. 4) Ran the tests and everything failed, even though it was passing on SVN :-( The issue was that the headers under boost/ were now *copies* of the last release and no longer pointers to the new "develop" code. Interestingly some of the hard links were updated when I ran bjam, but apparently not all :-( Running bjam -a fixes the issue, but it's a very easy trap for the unwary.... John. PS, one other very annoying issue for VC++ users: 1) Open a test file. 2) Select a #included boost file, right click and select "Open document". 3) Document opens, but gives you a copy under boost/ not the "real" header under libs/mylib/. 4) Run away screaming after you've spent an XXX hours editing the wrong file....

8 13

Possible issue with Boost.Atomic (and consequently Boost.Thread)
by Peter Dimov 04 Dec '13

04 Dec '13

In https://svn.boost.org/trac/boost/ticket/9466 it is reported that using Boost.Thread on AIX without defining BOOST_THREAD_DONT_USE_ATOMIC causes an assertion failure in boost/smart_ptr/detail/lwm_pthreads.hpp (pthread_mutex_lock failing with EINVAL.) As I explain in the ticket, what I think happens is that Boost.Atomic falls back to its generic lock pool implementation, which uses a static array of 41 boost::lightweight_mutex objects. However, since lightweight_mutex has a constructor calling pthread_mutex_init and a destructor calling pthread_mutex_destroy, using call_once, directly or indirectly, outside main can lead to accessing a mutex object before it's constructed or after it's destroyed, depending on static initialization order. If I'm correct in this assumption, then lockpool.hpp/.cpp need to be fixed to either use boost/smart_ptr/detail/spinlock_pool.hpp*, or use statically initialized pthread mutexes directly. *) Which is basically what it was designed for, see the comment: // spinlock_pool<0> is reserved for atomic<>, when/if it arrives

2 4