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

Problems compiling Boost_1_45_0
by Alex Biddulph 31 Dec '10

31 Dec '10

Hi all, I recently decided to try and compile/install Boost for my MSYS/MinGW64 system. I downloaded the lastest sources for both bjam (3.1.18) and Boost itself (1.45.0). (More precise details of my sytem are below). I compiled my own bjam with no hassle and got a bin.ntx86_64 version and copied it to /mingw/bin. I used the generic command to build it (./build.sh) and let it auto-detect the toolset (gcc). However, the compilation started to fall over once I started to build Boost itself. Using the command /mingw/bin/bjam --prefix=/mingw/boost toolset=gcc address-model=64 variant=release link=shared threading=multi --build-type=complete stage I first received the following error (attachment: error1.txt) After some googling I found a bug report where someone mention the workaround of just removing the 'ignore-minus-q' part of the statement, this removed the errors and allowed me to continue with the build. Is this an acceptable workaround or is there something else that I should be doing here? Anyways, I know receive the following errors (attachment: boost.txt and attachment: boostd2.txt) I did some googling again and found a bug report that is very similar to what I am getting (almost identical except for versions and setup). Here is the link to the bug report https://svn.boost.org/trac/boost/ticket/4839. The attachment boostd2 uses the exact same build command as above but with -d2 tacked on the end. Can anyone tell me why I am getting this and how I might fix it? Regards Bidski System details: OS: Windows 7 Home Premium x64 MinGW64: TDM64-GCC-4.5.1 $ gcc -v Using built-in specs. COLLECT_GCC=c:\mingw\bin\g++.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/4.5.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../src/gcc-4.5.1/configure --prefix=/crossdev/prefix-tdm64 --build=x86_64-w64-mingw32 --enable-targets=all --enable-libgomp --enable-lto --enable-libstdcxx-debug --enable-languages=c,c++,fortran,objc,obj-c++ --disable-werror --disable-nls --disable-win32-registry --enable-version-specific-runtime-libs --enable-fully-dynamic-string --with-pkgversion=tdm64-1 --with-bugurl=http://tdm-gcc.tdragon.net/bugs Thread model: win32 gcc version 4.5.1 (tdm64-1)

2 3

[Pool] Call for bug reports
by John Maddock 31 Dec '10

31 Dec '10

A small but intrepid band of volunteers will be updating Boost.Pool in the near future, so if there are any bug reports or feature requests you've been holding back... hold back no longer and please file these on the Trac. Wait too long to file though and you may have to wait another 10 years for an update.... although we certainly hope not! Regards, John.

1 0

[preprocessor] extending loop limit >> 256
by Martin Pasdzierny 31 Dec '10

31 Dec '10

Hi boost experts, using BOOST_PP_LOCAL_ITERATE() and friends I found the maximum number of iterations to be limited to 256. The according values seemed to be defined in .../preprocessor/config/limits.hpp But changing these values does *not* have any effect on the maximum number of iterations ... #define BOOST_PP_LOCAL_MACRO(n) g(n); #define BOOST_PP_LOCAL_LIMITS (1, 300 ) #include BOOST_PP_LOCAL_ITERATE() #undef BOOST_PP_LOCAL_MACRO #undef BOOST_PP_LOCAL_LIMITS ... still creates: g(1); g(2); g(3); ... g(255); g(256); the expected: g(257); g(258); ... g(299); g(300); are *not* generated. Stepping through the libraries code I found the mechanisms far more complicated than expected. Now my question: is there any recommended procedure to increase the iteration limitation to values like 10000 ? I found a couple of code locations explicitly repeating code with hard coded values from 1 ... 256. I guess at least this code needs to be extended, but probably consistent with some other changes. I am thinking of a perl script to generate stuff like that, but before working on that I'd like to get some qualified recommendations ;) Thanks in advance, Martin.

3 3

serialization: 2-arg template free function serialize
by Hicham Mouline 30 Dec '10

30 Dec '10

Robert, I have a number of types for which I've implemented the free serialize template function. I have also a number of fusion sequences. This is the code I came up with: namespace boost { namespace serialization { template <typename Archive> class SerializeMemberOfFusionSeq; /// fwd decl template <typename Archive, typename Seq> typename boost::enable_if_c<boost::fusion::traits::is_sequence<Seq>::value, void>::type serialize(Archive& ar, Seq& seq, unsigned int) { boost::fusion::for_each(seq, SerializeMemberOfFusionSeq<Archive>(ar)); } template <typename Archive> class SerializeMemberOfFusionSeq { public: SerializeMemberOfFusionSeq(Archive& ar) : ar_(ar) {} template <typename T> void operator()(T& t) const { ar_ & t; } private: Archive& ar_; }; } } Is the serialization library able to find the serialize() function this way? regards,

1 0

Mingw64 Boost Threads Build
by Dustin T. Clifford 30 Dec '10

30 Dec '10

Good Afternoon, We have been using boost-threads for our native APIs and, thus far, Boost has been a godsend! We had a recent request to build a 64-bit version of this API. To accomplish this we have attempted to build using MinGW64. Unfortunately, I have had zero luck getting boost-threads to build. I can build the 32-bit address model without a problem but 64-bit continues to elude me. I first tried Boost 1.35.0 and have now moved on to 1.45.0. I believe that the environment is set up correctly (see below). This build is being performed on a Windows 7 64-bit using MinGW64 from Cygwin. export CC=x86_64-w64-mingw32-gcc.exe export CXX=x86_64-w64-mingw32-g++.exe export LD=x86_64-w64-mingw32-ld.exe I have, also, modified my PATH to use the appropriate 64-bit bintools and aliased gcc, g++ and ld to the 64-bit MinGW64 compilers and linkers. To build Boost I have used the following with no success. boostrap.sh address-model=64 -prefix=<install> --with-libraries=thread; bjam -a install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a address-model=64 install; boostrap.sh -prefix=<install> --with-libraries=thread; bjam -a install; The last build attempt succeeds but appears to have built 32-bit binaries. The previous two fail in building boost-threads complaining that 'address-model-64' is not found for certain build artifacts. I have, also, tried the above with a prebuilt bjam with the same results. I have tried much more than what I have cited here (including MSVC builds) with no success (some built but resulted in 32-bit binaries). I have scoured Google and found many talking about this but most either had no resolution or contained instructions that conflicted or made no sense. Does anybody have any insight into how I can produce a 64-bit boost-threads archive? Any help would be greatly appreciated. Thanks in advance, Dustin P.S. If I have missed any information or you need more (build logs are attached), please, let me know.

1 0

taking the subgraph of a boost graph
by Ryan Lewis 30 Dec '10

30 Dec '10

Hi, Lets say your handed an arbitrary boost graph and an iterator to a subset of it's vertices. You want to induce a subgraph of this graph. How do you do this? I looked at the boost docs and found the Subgraph < Graph > page: http://www.boost.org/doc/libs/1_36_0/libs/graph/doc/subgraph.html Indeed there exists a subgraph member function: subgraph<Graph>& create_subgraph(); However this suggests, as does the example, that you want to take an induced subgraph of a graph whose type is Subgraph < Graph >. However my graph is just of type Graph. What is the right way to deal with this? I've tried asking at #boost, but no one seems to be awake there. Thanks, -rhl

4 15

[Proto] Bug in TArray Example
by Hossein Haeri 30 Dec '10

30 Dec '10

Dear all,wel;iqserhqweuo;h

1 1

[intrusive] linear hashing
by Ephraim Sinowitz 30 Dec '10

30 Dec '10

Hi, Can anyone explain the performance characteristics of linear hashing. I read the Wikipedia article and I'm still not sure. The article mentions growing the hash table incrementally by 1, but the instrusive unordered_set doesn't grow/rehash unless you tell it to? When does it make sense to use the linear hashing option? Why is it not on by default? Is it because it slows down the address lookup into the table. Is the ideal bucket size still 1 per expected element. Thanks -ephi

2 1

[MPL] Permutations of a List of Types
by Edward Terchunian 30 Dec '10

30 Dec '10

I am trying to create a list containing the permutations of a given type list. The below code seems to function, though without the intended result, when I use a specified list instead of generating a new list by removing from the actual input. This is demonstrated by the difference between permutation_helper and broken_helper below. Am I using remove incorrectly, or am I running into a different problem? #include <boost/mpl/list.hpp> #include <boost/mpl/transform.hpp> #include <boost/mpl/fold.hpp> #include <boost/mpl/push_front.hpp> #include <boost/mpl/joint_view.hpp> #include <boost/mpl/remove.hpp> #include <boost/mpl/assert.hpp> #include <boost/mpl/equal.hpp> namespace mpl = boost::mpl; struct test_type1 {}; struct test_type2 {}; struct test_type3 {}; template< typename T > struct permutations; template <typename value> struct permutations<mpl::list1< value > >: mpl::list1<mpl::list1< value > > {}; template< typename value, typename T> struct permutation_helper: mpl::transform< typename permutations< mpl::list1<test_type3> >::type, mpl::push_front< mpl::_1, value> > { }; template< typename value, typename T> struct broken_helper: mpl::transform< typename permutations< mpl::remove<T, value> >::type, mpl::push_front< mpl::_1, value> > { }; template< typename T > struct permutations: mpl::fold< T, mpl::list0<>, mpl::joint_view< mpl::_1, broken_helper<mpl::_2, T > > > { }; typedef mpl::list2<test_type1, test_type2> typelist; typedef permutations<typelist>::type perms; int main() { BOOST_MPL_ASSERT(( mpl::equal< perms, typelist > )); return 0; } I used the assert to determine what is being returned from the function, typelist is not the expected result. This is the message the assert returns for broken_helper: testcase.cpp: In function ‘int main()’: testcase.cpp:45: error: no matching function for call to ‘assertion_failed(mpl_::failed************ boost::mpl::equal<boost::mpl::joint_view<boost::mpl::joint_view<boost::mpl::list0<mpl_::na>, boost::mpl::l_end>, boost::mpl::l_end>, boost::mpl::list2<test_type1, test_type2>, boost::is_same<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >::************)’ The output using permutation_helper is an actual list: testcase.cpp: In function ‘int main()’: testcase.cpp:45: error: no matching function for call to ‘assertion_failed(mpl_::failed************ boost::mpl::equal<boost::mpl::list2<test_type1, test_type2>, boost::mpl::joint_view<boost::mpl::joint_view<boost::mpl::list0<mpl_::na>, boost::mpl::l_item<mpl_::long_<1l>, boost::mpl::l_item<mpl_::long_<2l>, test_type1, boost::mpl::list1<test_type3> >, boost::mpl::l_end> >, boost::mpl::l_item<mpl_::long_<1l>, boost::mpl::l_item<mpl_::long_<2l>, test_type2, boost::mpl::list1<test_type3> >, boost::mpl::l_end> >, boost::is_same<mpl_::arg<-0x00000000000000001>, mpl_::arg<-0x00000000000000001> > >::************)’

2 1

pthread_exit() from boost::thread segfaults ?
by Viatcheslav.Sysoltsev＠h-d-gmbh.de 30 Dec '10

30 Dec '10

Hi people, does anybody have an idea why the following simple programm segfaults: #include <boost/thread.hpp> void tf() { pthread_exit(NULL); } int main() { boost::thread t(tf); t.join(); return 0; } > g++ test2.cpp -lboost_thread && gdb a.out GNU gdb (GDB) 7.2 Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/vsysolts/test/boost_thread/a.out...done. (gdb) r Starting program: /home/vsysolts/test/boost_thread/a.out [Thread debugging using libthread_db enabled] [New Thread 0x7ffff6cd5950 (LWP 21145)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff6cd5950 (LWP 21145)] 0x00007ffff798a565 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6 (gdb) bt #0 0x00007ffff798a565 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6 #1 0x00007ffff7988a46 in ?? () from /usr/lib64/libstdc++.so.6 #2 0x00007ffff7988a73 in std::terminate() () from /usr/lib64/libstdc++.so.6 #3 0x00007ffff7bd898a in thread_proxy () from /usr/lib64/libboost_thread.so.1.36.0 #4 0x00007ffff6cdd070 in start_thread () from /lib64/libpthread.so.0 #5 0x00007ffff71ce11d in clone () from /lib64/libc.so.6 #6 0x0000000000000000 in ?? () (gdb) I am using opensuse 11.1, x86_64 architecture, gcc 4.3.2, boost 1.36 -- Slava

2 1