- Boost-users - lists.boost.org

adding 'blackberry' to boost build
by Gottlob Frege 23 Oct '12

23 Oct '12

I work for RIM (ie BlackBerry), and am trying to make using boost as easy as possible to use for BB developers. So I would like to make building boost for BB as easy as possible. I would also like to make building boost work "as expected" for anyone who understands Boost.Build. It is the "as expected" part that I'm not sure of. ie should I just offer a blackberry-config.jam? should Boost.Build be changed to auot-detect the BB NDK? should blackberry be a toolset? a target-os? ...? how would you *expect* it hook into Boost.Build? (And note that I expect that developers *also* use the same boost for Windows, etc, so I don't want to replace/affect the simple build for the host machine.) - And finally, it would be nice if this was upstreamed back into boost build (if people think that makes sense), so that boost "just works" on BlackBerry. Here's what I have so far: from the command line, you run something like: b2 install --prefix=C:\boost\ --user-config=blackberry-config.jam --layout=system toolset=gcc target-os=qnxnto I'd prefer it if they didn't need to type so much. And the config file looks like basically the rest of this email: import os ; # these env vars are set by installing the BB NDK QNX_TARGET_ARCH = [ os.environ QNX_TARGET_ARCH ] ; QNX_TARGET = [ os.environ QNX_TARGET ] ; QNX_HOST = [ os.environ QNX_HOST ] ; if ! $(QNX_TARGET) || ! $(QNX_HOST) { ECHO error: ; ECHO error: BlackBerry build of Boost requires QNX_TARGET and QNX_HOST env variables. Did you run bbndk-env.bat? ; ECHO error: ; EXIT ; } if $(QNX_TARGET_ARCH) = x86 { dashVOpt = gcc_ntox86_cpp ; linkArchDir = x86 ; } else { dashVOpt = gcc_ntoarmv7le_cpp ; linkArchDir = armle-v7 ; } using qcc # Version : # C++-compile-command : $(QNX_HOST)/usr/bin/QCC -V$(dashVOpt) # Compiler options : <compileflags>"-D__QNX__" <compileflags>"-D__QNXNTO__" # Add -D__USE_ISOC99 for rounding control mechanism (boost/numeric/interval/hw_rounding.hpp) <compileflags>"-D__USE_ISOC99" <compileflags>"-I$(QNX_TARGET)/usr/include" # Prevent this from being output: "note: the mangling of 'va_list' has changed in GCC 4.4" <compileflags>"-Wno-psabi" # Add -fPIC to link without error to LibTestNativeLibTuTest.o (for statechart tests) <compileflags>"-fPIC" # Requested by BBM team <compileflags>"-fno-strict-aliasing" # Functions like sync_val_compare_and_swap and sync_fetch_and_add aren't available <compileflags>"-DBOOST_SP_NO_SYNC" <linkflags>"-L$(QNX_TARGET)/$(linkArchDir)/usr/lib -L$(QNX_TARGET)/$(linkArchDir)/lib" ; import option ; option.set keep-going : false ; ------------------------ Thanks in advance, Tony

2 2

building universal boost binaries (MacOS)
by Nick Zavaritsky 23 Oct '12

23 Oct '12

Hi! Boost.build docs says that to build 'fat' binaries on the Mac two options exist: architecture=combined and/or address-model=32_64. The first one builds a binary with PowerPC and x86 code. The second one builds a binary with 32 and 64bit code. The doc further states that architectire= and address-model= are independent: one can use the first one alone or the second one alone or both simultaneously yielding different results. (http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.r…) I would like to use address-mode=x86_64 to build x86/x86_64 fat binaries of boost libraries. Unfortunately with boost 1.51 it doesn't work this way — in order to get fat binaries one has to specify both architecture=combined and address-mode=32_64. Since we don't want power pc support we strip binaries from ppc code using lipo. This is a very suboptimal solution since we compile ppc variant anyway and that takes time. Even worse is that the modern toolchain doesn't support PowerPC hence we have to compile Boost using older toolchain. Currently address-model=32_64 works only if architecture=combined was specified as well (tried with Xcode 4.5 and 3.2.5). Is this really a bug in Boost.build? If that is by design what is the method to build boost fat binaries with modern toolchain lacking ppc support?

1 0

Re: [Boost-users] [EXTERNAL] Re: [MPI] missing symbols using serialization's static library design
by Robert Ramey 23 Oct '12

23 Oct '12

"Barrett, Brian W" <bwbarre(a)sandia.gov> wrote in message news:<69A29AB53D57F54D81061A9E4E45B8FD239CC111(a)EXMB01.srn.sandia.gov>... > On 10/17/12 1:00 PM, "Robert Ramey" <ramey(a)rrsd.com> wrote: > > >Barrett, Brian W wrote: > >> > Unfortunately, I'm barely competent in using Boost.MPI and > Boost.Serialization. I'm definitely not in a position to be able to apply > a patch. > > What I'm getting from your responses and the general silence elsewhere is > that the right answer is to deal with the incompatibilities between > versions of Boost and explicitly instantiate all the internal MPI > archivers and hope for the best. It's a little painful, but I think we > can do that. Well, your organization could contract with me to address this for you. I've done special work for several companies which use the serialization library. This work has been contributed to boost and become part of the distributed package. So a) The organization gets what it needs for a reasonable cost. b) Any generally useful enhancements get included in the library So it helps everyone all around. Thanks in advance for considering this. Robert Ramey > > Thanks, > > Brian > > -- > Brian W. Barrett > Scalable System Software Group > Sandia National Laboratories

3 4

[system] symbol visibility and GCC vs. Clang
by James Walker 23 Oct '12

23 Oct '12

When trying to link a bunch of libraries on OS X, I got this linker warning: ld: warning: direct access in boost::system::system_error::~system_error() to global weak symbol vtable for boost::system::system_error means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings. As far as I can tell, everything is compiled using the flags -fvisibility=hidden -fvisibility-inlines-hidden. I'm wondering whether the problem is that some of the libraries were built using gcc and some were built using Clang. In boost/system/system_error.hpp, the declaration of boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be __attribute__((visibility("default"))), whereas boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/>

2 2

Re: [Boost-users] Interesting article on stack-based TMP
by Thorsten Ottosen 23 Oct '12

23 Oct '12

On 23-10-2012 15:05, Larry Evans wrote: > On 10/22/12 07:26, Giovanni Piero Deretta wrote: > [snip] >> Now, to make this thread on-topic: is anybody working on a C++11 >> rewrite of Boost.MPL? >> > Anyone attempting such a rewrite and planning to use the > variadic template features might want to start from: > > http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/mpl/ > > However, using variadic templates may cause a slowdown in the > compile times. IIRC, a variadic template version of proto was > developed but was abandoned in favor of using: > > http://www.boost.org/doc/libs/1_51_0/libs/preprocessor/doc/index.html > > because of large compile times. Hm. This is really sad if variadic templates can't be used for the thing they were created for. Is this an inherent problem for large-scale use of variadic templates? -Thorsten

2 1

asio: how to handle disk IO, recommendations
by Avi Bahra 23 Oct '12

23 Oct '12

Currently I has a single threaded server based on boost ASIO. This works correctly most of the time. However on systems where i know that the disk's are slow. , the server grinds to a halt, when dealing with the blocking disk IO. I could not find any examples or documentation in ASIO, in how to get round these issues. It appears that ASIO does not provide any support for async' disk IO. So I assume this is handled by use of threads ? Are there any examples of using ASIO with threaded disk IO, since this must be very common use case ? Is the strand functionality appropriate for handing disk IO, in an async' manner. Any recommendations/advice on this issues would be greatly appreciated. Best regards, Ta, Avi

2 1

Boost install creates no boost library files
by niallm 22 Oct '12

22 Oct '12

Hi guys, I'm running OS X 10.8.2 and I'm trying to install boost. I'm using Enthought python. So I've unpacked the tar file boost_1_51_0.tar.bz2 into usr/local. Then in the resulting directory boost_1_51_0, I do the following commands: $ ./bootstrap.sh --with-python=2.7 --with-python-root=../../Library/Frameworks/EPD64.framework /Versions/Current/bin/python then: $ ./b2 link=shared --with-python --with-math (I only need the python and math parts). This returns: he Boost C++ Libraries were successfully built! The following directory should be added to compiler include paths: /usr/local/boost_1_51_0 The following directory should be added to linker library paths: /usr/local/boost_1_51_0/stage/lib Then I did: $ sudo ./b2 --prefix=usr/local link=shared --with-python --with-math install This returns: common.mkdir usr common.mkdir usr/local common.mkdir usr/local/include common.mkdir usr/local/include/boost Followed by lots of lines starting 'common.copy...' and finished with '...updated 9752 targets...'. However when I check in usr/local/include there is no boost directory, and there are no boost libraries in usr/local/lib Thanks in advance -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-install-creates-no-boost-library-f… Sent from the Boost - Users mailing list archive at Nabble.com.

3 2

[graph] Extending bgl_named_params
by Philipp Moeller 22 Oct '12

22 Oct '12

Hi, I maintain a library that introduces its own graph properties for domain specific algorithms and provides it's own implementation of bgl_named_parameters by essentially mimicking bgl_named_parameters one-to-one. With the refactoring in 1.51 that implementation broke and I had to add another implementation of named parameters which essentially looks like this: enum my_property_t { my_property }; template <typename T, typename Tag, typename Base = boost::no_property> struct foo_bgl_named_params : boost::bgl_named_params<T, Tag, Base> { typedef boost::bgl_named_params<T, Tag, Base> base; typedef foo_bgl_named_params self; foo_bgl_named_params(T v = T()) : base(v) {} foo_bgl_named_params(T v, const Base& b) : base(v, b) {} template <typename PMap> foo_bgl_named_params<PMap, my_property_t, self> my_property_map(const PMap& p) const { typedef foo_bgl_named_params<PMap, my_property_t, self> Params; return Params(p, *this); } }; // the respective free functions... template <typename PMap> foo_bgl_named_params<PMap, my_property_t, self> my_property_map(const Pmap& p) const { typedef foo_bgl_named_params<PMap, my_property_t, self> Params; return Params(p); } // partial specialization for lookup_named_param_def namespace boost { template <typename T, typename Tag, typename Base, typename Def> struct lookup_named_param_def<Tag, foo_bgl_named_params<T, Tag, Base>, Def> { typedef T type; static const type& get(const bgl_named_params<T, Tag, Base>& p, const Def&) { return p.m_value; } }; template <typename Tag1, typename T, typename Tag, typename Base, typename Def> struct lookup_named_param_def<Tag1, foo_bgl_named_params<T, Tag, Base>, Def> { typedef typename lookup_named_param_def<Tag1, Base, Def>::type type; static const type& get(const bgl_named_params<T, Tag, Base>& p, const Def& def) { return lookup_named_param_def<Tag1, Base, Def>::get(p.m_base, def); } }; } // boost This is brittle because it the type returned by the inherited functions is not the same and chaining will not work if one of those functions is called first, e.g. all custom properties have to be chained together first. >From the documentation it is not really obvious to me if other libraries are even supposed to provide their own properties and how/if they actually should be able to extend the named parameters API. Is that simply not an intended feature of the BGL or can that be done differently? Cheers, Philipp

2 1

Linking issue with Boost 1.44 and GCC 4.6
by Joseph Sulewski 21 Oct '12

21 Oct '12

Hi, I'm having a very strange compilation issue with Boost. I've used boost in other C++ projects in the past and have had no issues. I'm writing a program to compile against Hypertable which relies on the boost 1.44 version of the library. I'm writing this on Intel Linux and compiling with GCC 4.6.3 Here is my linker command. I removed the .o's from my application to make it simpler to read: g++ -L/opt/hypertable/current/lib -L/home/l3/development/libraries/boost_1_44_0/stage/lib -pthread -o "AppLogger" MYDOT-O-FILES.o -lboost_system -lboost_iostreams -lboost_filesystem -lboost_program_options -lboost_thread -lsigar-x86-linux -lz -lHypertable -lHyperspace -lHyperTools -lHyperComm -lHyperCommon As you can see I'm including a number of boost libraries but I'm getting a lot of very strange errors. For example, opt/hypertable/current/lib/libHypertable.a(Client.cc.o): In function `Hypertable::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)': Client.cc:(.text+0x26a5): undefined reference to `boost::program_options::variables_map::variables_map()' >From what I can see the precompiled library from Hypertable is not finding the functions in the boost library. Here is another I get Client.cc:(.text+0x26a5): undefined reference to `boost::program_options::variables_map::variables_map()' /opt/hypertable/current/lib/libHypertable.a(Client.cc.o): In function `Hypertable::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)': I get a bunch of these: HqlInterpreter.cc:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x151): undefined reference to `boost::detail::once_epoch_cv' There are many many more linker errors but I didn't want to clog up the system with all the errors. Any ideas would be greatly appreciated Thanks

3 5

[proto] transform with calling templates
by Felipe Magno de Almeida 21 Oct '12

21 Oct '12

Hello, I had the following transform and function object: struct bind_functions_transform : proto::when < proto::terminal<binding::placeholder::method_value<proto::_,proto::_> > , bind_method_call(proto::_value, proto::_data, proto::_state)> > struct bind_method_call : proto::callable { template <typename T> struct result { typedef typename boost::function_types::parameter_types<T>::type parameter_types; typedef typename boost::mpl::next <typename boost::remove_reference <typename boost::mpl::at_c<parameter_types, 2u>::type>::type>::type type; }; template <typename Sig, typename F, std::size_t I, std::size_t N> boost::mpl::size_t<I+1> operator()(binding::placeholder::method_value<Sig, F>const& method , boost::fusion::vector<Class&, environment, binding::virtual_table<N>&>& data , boost::mpl::size_t<I> v) const { ... } }; So, I needed one more compile-time information which would be equal to all calls and transforms, so I made my transform into a template and also bind_method_call as follows: template <typename T> struct bind_functions_transform : proto::when < proto::terminal<binding::placeholder::method_value<proto::_,proto::_> > , bind_method_call<T>(proto::_value, proto::_data, proto::_state)> > template <typename T> struct bind_method_call : proto::callable [...] And then I received the following error: ../boost_1_50_0/boost/proto/transform/detail/preprocessed/construct_funop.hpp:24:33: error: no matching function for call to ‘jvb::binding::bind_method_call<hello_world>::bind_method_call(const jvb::binding::placeholder::method_value<void(), void (hello_world::*)()>&, boost::fusion::vector<jvb::class_&, jvb::environment, jvb::binding::virtual_table<1ul>&, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_, boost::fusion::void_>&, const mpl_::size_t<0ul>&)’ I've remembered the workaround for msvc with proto::call. Because it seemed that the transform was actually trying to construct instead of calling bind_method_call, so I changed to: template <typename PeerClass> struct bind_functions_transform : proto::when < proto::terminal<binding::placeholder::method_value<proto::_,proto::_> > , proto::call<bind_method_call<PeerClass>(proto::_value, proto::_data, proto::_state)> > And it worked. Well, my question is: is this a known limitation? I didn't find it in proto documentation. I'm using GCC 4.7.1 and x86_64 with Linux Regards, -- Felipe Magno de Almeida

2 1