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

boost 1.49.0 on Redhat 5.2 link issues
by Stefan Schwarzer 13 Jun '13

13 Jun '13

Dear everybody, we need to backport boost 1.49.0 to Redhat 5.2. b2 ; b2 install --prefix=/usr/local succeeds and installs libraries and headers in /usr/local as requested (g++ 4.1.2-42, 32 bit PAE kernel). However, we have a problem even linking a mostly trivial example: #include <boost/filesystem.hpp> int main () { copy_file(boost::filesystem::path("atest"), boost::filesystem::path("btest")); } $ g++ testBoost.cpp -lboost_filesystem -lboost_system /tmp/cc10doAS.o: In function `boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)': testBoost.cpp: (.text._ZN5boost11filesystem39copy_fileERKNS0_4pathES3_[boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)]+0x24): undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_type, boost::system::error_code*)' collect2: ld returned 1 exit status The symbol is present in /usr/local/lib/libboost_filesystem and ldconfig does know about its location (see below). Also, trying to link statically or adding -pthread does not change the situation. We are desperate for advice... Roald and Stefan. $ nm -C /usr/local/lib/libboost_filesystem.so | grep 'boost::filesystem3::detail::copy_file' 00010ae0 T boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_type, boost::system::error_code*) $ cat /etc/ld.so.conf include ld.so.conf.d/*.conf /usr/local/lib

2 2

boost::thread::attributes reference overload?
by Anthony Foiani 13 Jun '13

13 Jun '13

Greetings. I have a class that wraps a boost::thread object, and I would like to specify certain thread attributes at construction time. My first attempt looked basically like this: struct my_thread { static boost::thread::attributes getThreadAttr() { boost::thread::attributes attrs; attrs.set_stack_size( 256 * 1024 ); return attrs; } my_thread( Runnable func ) : thread_( getThreadAttr(), func ) {} boost::thread thread_; }; But that fails: g++ -std=c++0x -o thread-attr thread-attr.cpp \ -lboost_thread-mt -lboost_system -pthread ... /usr/include/boost/thread/detail/thread.hpp:191:9: note: \ template argument deduction/substitution failed: thread-attr.cpp:48:42: note: cannot convert ‘my_thread::getThreadAttr()()’ (type \ ‘boost::thread::attributes {aka boost::thread_attributes}’) to type ‘boost::thread::attributes& {aka boost::thread_attributes&}’ Replacing 'getThreadAttr' with a method that returns a non-const reference to internal static variables allows the program to compile and run successfully: static boost::thread::attributes & getThreadAttr() { static boost::thread::attributes attrs; static bool init = false; if ( ! init ) { attrs.set_stack_size( 256 * 1024 ); init = true; } return attrs; } The full program, with Linux compile lines, can be found at the bottom of this message and also at: http://foiani.home.dyndns.org/~tony/boost/thread-attr.cpp I did find a closely-related question on StackOverflow: http://stackoverflow.com/questions/13868619 Where Vicente replied (http://stackoverflow.com/a/13894968/784478) The needed overload template <class F, class Arg, class ...Args> thread(attributes const& attrs, F&& f, Arg&& arg, Args&&... args) is defined only if the compiler supports variadic templates and rvalue references. This could explain your problem. I guess the documentation could be improved to signal this clearly. Please could you create a Trac ticket to follow this issue? However, the compiler I'm using (g++ 4.7.2) has supported both of these features for years. According to this page: http://gcc.gnu.org/projects/cxx0x.html g++ has supported both of these features since 4.3. Josef_K (on freenode IRC #boost channel) was kind enough to try the sample code in their own environment, and they encountered the same errors on both g++ 4.8.1 and clang 3.4. The most likely explanation is that I'm doing something stupid. If anyone has the time to hit me with the clue-by-four, I would appreciate it. There is the possibility that Boost.Thread v4 fixes this (I'm on 1_51_0, which is Boost.Thread v3.0.1). I'd rather not try to transition libraries at this point, but if it has been fixed, confirmation would be welcome. For now, I'll most likely implement the "return reference to internal static" method in my project. It's a bit racy, but since I do all my thread creation through this one routine, I should be able to manage it. Anyway. I'm left feeling that there is a gap somewhere; whether it's in my understanding, in the older version of Boost.Threads, in compiler support / quirks, or elsewhere, I don't know. Regardless, thanks for the excellent library, and happy hacking! Best regards, Anthony Foiani Sample program follows: ======================================================================== // this should work: // g++ -std=c++0x -o thread-attr thread-attr.cpp -lboost_thread-mt -lboost_system -pthread // // this explodes: // g++ -std=c++0x -o thread-attr thread-attr.cpp -DRVALUE_REFERENCE_DOOM -lboost_thread-mt -lboost_system -pthread #include <iostream> #include <boost/function.hpp> #include <boost/thread.hpp> typedef boost::function< void ( void ) > Runnable; struct my_thread { #ifdef RVALUE_REFERENCE_DOOM // this doesn't work. static boost::thread::attributes getThreadAttr() { boost::thread::attributes attrs; attrs.set_stack_size( 256 * 1024 ); return attrs; } #else // this does work, but needs more structure before it can be // considered safe. static boost::thread::attributes & getThreadAttr() { static boost::thread::attributes attrs; static bool init = false; if ( ! init ) { attrs.set_stack_size( 256 * 1024 ); init = true; } return attrs; } #endif my_thread( Runnable func ) : thread_( getThreadAttr(), func ) {} void join() { thread_.join(); } boost::thread thread_; }; void foo() { std::cout << "foo!" << std::endl; } int main( int argc, char * argv [] ) { my_thread t( foo ); t.join(); return 0; }

2 1

Re: [Boost-users] [multi_index] emplace support
by Brian Wood 13 Jun '13

13 Jun '13

> The sad reality is I have very limited time to devote to evolving the > library, so this thing, although in principle simple to implement, has > been procrastinated for years now. Maybe if you sketch the first step that needs to be done here on the list someone will do that and then you can repeat for each step. Whoever would be willing to do this should ask the questions they have here, because there are a number of others on this list who can answer at least some of the questions. A tip to someone willing to do this: Boost Container has emplace support: http://www.boost.org/doc/libs/1_53_0/doc/html/container/move_emplace.html#c… so studying that implementation might be helpful. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Output libs to specified folder
by Christopher Pisz 12 Jun '13

12 Jun '13

How can I tell boost to put the libraries in a directory that I specify? If I change stage-dir, it still appends /lib onto it. Is this possible? I want my libraries in C:\trunk\third_party\ Not in C:\trunk\third_party\lib Here is my build script: cd ..\boost SET PATH=$(PATH);..\bjam bjam.exe --stagedir=../../third_party --with-thread toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-date_time toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-system toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-regex toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-program_options toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-filesystem toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage

1 0

[chrono] Initializing system_clock from microseconds
by Kelly, Dan 12 Jun '13

12 Jun '13

I have been having some difficulty initializing a chrono::system_clock::time_point object. Specifically, I am trying to load a time stamp from a .pcap file using libpcap. I have a structure, pcap_pkthdr, which contains two fields: struct timeval { long tv_sec; /* seconds */ long tv_usec; /* and microseconds */ }; struct pcap_pkthdr { struct timeval ts; /* time stamp */ bpf_u_int32 caplen; /* length of portion present */ bpf_u_int32 len; /* length this packet (off wire) */ }; Where tv_sec and tv_usec are seconds and microseconds respectively relative to an epoch of Jan 1, 1970. I can use system_clock::from_time_t() to initialize the time_point to an 64-bit integer seconds (std:time_t). The question is, how do I add the microseconds to this value? My latest attempt is: void my_class::calculate_packet_statistics( const struct pcap_pkthdr *header ) { frame_interval_.intervalTimeStamp_ = system_clock::from_time_t( static_cast<time_t>( header->ts.tv_sec ) ); frame_interval_.intervalTimeStamp_ += microseconds( header->ts.tv_usec ); // This is the problematic line ... } However, this appears to simply add tv_usec to the internal representation of the time_point. The internal representation appears to be in 100ns ticks with an epoch other than Jan 1, 1970. This is on a windows x64 build but the same code will have to work on Linux as well. As a side note, I later do some date calculations using system_clock::to_time_t. I lose my fractional seconds here But since I am only working with dates, this is not a problem. Dan Kelly dan.kelly(a)sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 4

Question about the segfault in path::imbue that is being worked on at the moment
by Lars Hagström 12 Jun '13

12 Jun '13

Hi, I'm being bitten by the bug discussed here http://boost.2283326.n4.nabble.com/filesystem-segfault-in-path-imbue-after-… I'm encountering this when using boost 1.50. I have to support multiple boost versions, so I may bump into this in other versions as well. >From looking at the commit logs of boost svn I see that this is being worked on at the moment. But I would like to know what versions this bug affect, and if there are any ideas for a workaround. To me it looks like it affects most versions of boost filesystem, and I have been unable to come up with a workaround other than removing all use of filesystem in any place that could be called before main() has started. I would really like not having to do that! We use it quite a lot during static initialization... I've tried calling imbue(...) and codecvt() manually before using path, but that doesnt really help. The path_locale is in an anonymous namespace, which stops me from initializing it myself... Any other ideas? Sincerely Lars

1 0

[Interprocess] Interest in a NamedPipe component
by Geoff Shannon 11 Jun '13

11 Jun '13

Hey all, I'm in the early stages of planning an independent study for my CS program and what I'm hoping to do is write a Boost.Interprocess compatible implementation of NamedPipe. However, I don't want what I create to be too closely tied to what I personally want to use. So, if you have any possible interest in utilizing such a feature, please respond and we can chat a bit about what the desirable semantics might be. Specifically I'm interested in comments on what kind of persistence people would lke, and thoughts about whether the stream should be message oriented or not (or optionally so). (see http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/some_basic_expla… for more info about what I mean by persistence). Right now, my conception of what the key features of a NamedPipe implementation would be is a stream/message oriented communication channel between to unrelated processes. thanks! -- Geoff Nothing is ever easy.

1 0

quantil
by Philipp Kraus 11 Jun '13

11 Jun '13

Hello, I would like to create a box plot and use the static calls of the boost. Median / average etc works well, but I need also the 25% & 75% quantil of my data, I'm using a boost::accumulators::accumulator_set for calculating statistical data. Can I / How can I use this for the quantil calculation or should I do this myself? Thanks Phil

3 9

asio 1.43 ssl client certificate failure
by Stephan Menzel 11 Jun '13

11 Jun '13

Hello all, I am struggling with a bit of an esoteric question and have been debugging for days now. Basically, I am outfitting an existing app with asio based ssl HTTPS. Clients will have to use client authentication. Have my own root CA that signs both client and server certs. Extensive debugging using OpenSSL's s_client and s_server tools shows that the certificate trust chain etc is OK. Server side works fine with browsers, requests client certificate from browsers and only allows access if present. Alas, I can't get the client side to work. in boost 1.43 asio did not yet have any verification callbacks but it does have this: m_ssl_context.set_options( asio::ssl::context::tlsv1_client | asio::ssl::context::default_workarounds ); m_ssl_context.set_verify_mode( asio::ssl::context::verify_peer ); m_ssl_context.load_verify_file( myrootca ); m_ssl_context.use_certificate_file( myclient_cert, asio::ssl::context::pem ); m_ssl_context.use_private_key_file( myclient_key, asio::ssl::context::pem ); When I debug this using openssl s_server I see the connection failing with this message: ... SSL_accept:SSLv3 write certificate request A SSL_accept:SSLv3 flush data read from -0x7ff81be0 [-0x7ff8e2dd] (5 bytes => 5 (0x5)) 0000 - 16 03 01 00 07 ..... read from -0x7ff81be0 [-0x7ff8e2d8] (7 bytes => 7 (0x7)) 0000 - 0b 00 00 03 .... 0007 - <SPACES/NULS> write to -0x7ff81be0 [-0x7ff77a80] (7 bytes => 7 (0x7)) 0000 - 15 03 01 00 02 02 28 ......( SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client certificate B 2675716:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3274: ACCEPT A s_client or browser with the exact same keys can connect. Only asio fails and only on the client. Debugging shows that the client won't send the requested SSL certificates to the server. Also, when I register a verification callback in the impl like that: SSL_CTX *ctx = m_ssl_context.impl(); SSL *ssl = m_ssl_socket.impl()->ssl; SSL_CTX_set_client_cert_cb(ctx, &client_certificate_callback); and always return 1 in the callback, it still fails. Unfortunately I cannot upgrade to a post-war boost version and cannot touch OpenSSL either. It is on Windows here and uses OpenSSL 0.9.8i as far as I can see. Am I screwed? Or does anyone have an idea? Much appreciated? Stephan

2 2

[program_options] Can I use shorthand options with more than one char?
by Stefan Köhnen 10 Jun '13

10 Jun '13

Hello, I am currently migrating an old application with some weird command-line arguments. While using Boost program_options, I try to keep some of those arguments from the old version of the application, to assure the compatibility of some user scripts. My problem is that I couldn't find a way to add shorthand options with two or more characters. For example, if I add: ("testOption,to", "This is just a test-option") to the options_description, I only get -t as the shorthand for testOption. Is there some way to use longer shorthand options? Greetings, Stefan Köhnen

1 0