- Boost - lists.preview.boost.org

[Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
by Matthew Chambers 27 Oct '12

27 Oct '12

I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list. How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build." How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC? Thanks, -Matt > (2012/10/17 0:09), Matthew Chambers wrote: >> On 10/15/2012 11:29 PM, Steven Watanabe wrote: >>> AMDG >>> >>> On 10/15/2012 07:54 PM, Kohei Takahashi wrote: >>>> Hi all, >>>> >>>> Can anyone handle following two issues? >>>> >>>> <runtime-debugging>on does nothing for libstdc++... >>>> https://svn.boost.org/trac/boost/ticket/4589 >>>> >>> >>> This is /not/ a trivial issue. It may be easy to do, but: > > I understood about this is not trivial issue and I changed the subject. > > >>> a) _GLIBCXX_DEBUG was broken last time I tried it a few years >>> ago. It won't work with all versions of gcc. >> >> I've used it with 4.1.2 and it helped a lot to track down some >> mysterious failures. > I don't know about old releases but recents seem to work well for me. > Indeed, expects to work well and should work with all versions of gcc > if define it by default. > >>> b) Anything the changes the ABI of the compiled libraries needs >>> careful consideration and must be documented. The libraries that >>> are built need to be ABI compatible with code that isn't >>> compiled using Boost.Build. >> >> Is it really that important that debug builds be ABI compatible >> between disparate builds? I think it's reasonable to EXPECT trouble >> when linking a debug build to precompiled libraries. That is >> certainly the case on Windows. > > <define> is not propagated feature, that means to trigger unexpected > link failure or ABI breaking. I think that using <runtime-debugging> > make safely rather than <define>. > I think it is better that provides propagated feature (as > <runtime-debugging> or another) for such purpose at least. > > >>> c) <runtime-debugging>on is part of <variant>debug, but I don't >>> think _GLIBCXX_DEBUG is a standard part of debug builds with >>> gcc. >> >> What is a "standard" debug build with gcc? Most people would >> probably say -g and -O0 but that doesn't provide any real debugging >> support. >> >> I agree it's not trivial, but having a no-op runtime-debugging >> feature is cringe-worthy. It's as good as admitting that GCC (or >> rather, libstdc++) doesn't provide any "official" runtime debugging >> support which is unfair. >> >> In the spirit of upcoming elections, count this as a vote for >> turning on _GLIBCXX_DEBUG. :)

5 4

Relationship of Boost libraries to TR1 and C++11
by Dave Abrahams 27 Oct '12

27 Oct '12

I don't suppose anyone has written up the specific differences between Boost libraries like regex, bind and shared_ptr and their TR1 and C++11 counterparts? It would be great if the maintainers of libraries that were accepted could add a FAQ about that. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

BoostCon old videos
by Fernando Pelliccioni 27 Oct '12

27 Oct '12

Does anyone know where I can get the videos of previous years BoostCon? In particular I am looking for the following: "Cross-platform development with Qt and Boost" http://blip.tv/boostcon/joao-p-r-abecasis-cross-platform-development-with-q… Thanks and regards, Fernando Pelliccioni.

5 5

Fwd: Re: [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 26 Oct '12

26 Oct '12

-------- Original Message -------- Subject: Re: [system] symbol visibility and GCC vs. Clang Date: Tue, 23 Oct 2012 10:40:42 -0700 From: James Walker <jamesw(a)frameforge3d.com> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org CC: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Newsgroups: gmane.comp.lib.boost.user References: <5085BABE.9030609(a)frameforge3d.com> <50868205.6070508(a)ens-lyon.org> On 10/23/2012 4:39 AM, Mathias Gaunard wrote: > On 22/10/12 23:29, James Walker wrote: >> 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. > > This looks like a significant bug, POSIX-style symbol visibility doesn't > work with Clang. > Please file a ticket. OK, thanks. <https://svn.boost.org/trac/boost/ticket/7559> -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/>

2 1

[thread] terminating destructor
by Andrzej Krzemienski 26 Oct '12

26 Oct '12

Hi, I can see in the release notes that in Boost 1.52 boost::thread's destructor calls terminate if joinable, in order to conform to C++11 specification. I am not sure if this is the best course of action. My understanding -- form the C++ Committee papers and informal presentations -- is that the reason for introducing a 'terminating destructor' was the lack of thread cancellation/interruption functionality. Thread interruption is supposed to be the preferred behavior for thread's destructor. std::thread does not support interruption (for some reasons), but boost::thread does (this is already a departure from C++11), so shouldn't the latter prefer to interrupt a joinable thread in the destructor? Regards, &rzej

9 41

Re: [boost] [Boost-build] another simple boost build failure
by Jürgen Hunold 25 Oct '12

25 Oct '12

Hi Ronny, On Thursday, 25. October 2012 12:55:10 you wrote: > thanks a lot. I did not know that one has to rebuild everything after > changing the requirements. It seems to work now. Good to hear that everything is up and running. > It is true, I did not read the starting guide thoroughly, I'll do that now > :-). Good, too ;-) > I am a bit confused about the library being a static library. Shouldn't it > be "boost_filesystem-vc90-mt-gds-1_50.lib" instead of > "boost_filesystem-vc90-mt-gd-1_50.lib" then? Or did I get it wrong? Ah, that is the "s" for static runtime. AFAIK the last msvc to provide a static runtime was 7.1. Don't confuse "static library" with "static runtime libraries". The static runtime opens up a new can of worms... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[Program Options] terminate parsing after first positional argument
by Evan Driscoll 25 Oct '12

25 Oct '12

This summer there was some discussion on the boost-users list about whether it is possible to use program_options to write an interface like 'xargs' (or time, or env, or nohup, or ssh, or sudo, or valgrind, or Python, or lots of other tools) where any options (--foo) that appear after the first positional arguments are considered positional arguments. In other words,'xargs foo --help' in real Unix behaves the same as 'xargs -- foo --help', rather than 'xargs --help foo', but you can't get this behavior currently from Boost. I proposed a couple patches, and there was a very small amount of discussion, but it sort of petered out (in part because I went away for a couple weeks at an inopportune time). Is there any interest in adopting them? The bug I filed just got another hit from someone else who wants it. https://svn.boost.org/trac/boost/ticket/6991 The following is a summary of the status: The ideal would be to have an 'allow_interspersed' style option which would be set by default (to give the now-usual behavior of "cmd arg --opt" being the same as "cmd --opt arg") but which a client program could unset if they wanted the xargs-like behavior. However, I don't see how to do this, because > If someone says > style_t style = allow_short | allow_slash_for_short > I can't automatically go and set allow_interspersed for them as well. And so without some ugly and not-worth-it coding tricks (changing style_t to a class), unless I'm missing something you can't pick this ideal without breaking backwards compatibility. So I instead suggested a new 'disallow_interspersed' style option, which would be off by default (keeping backwards compatibility) but you could set it to get xargs-like behavior, but this is inconsistent with all the other style flags which are allow_xxx. So what do you want to do regarding this issue? References: Trac issue: https://svn.boost.org/trac/boost/ticket/6991 (includes a patch for both of those options) The previous messages in this discussion, on boost-users: http://lists.boost.org/boost-users/2012/07/75100.php Evan

1 0

Using libc++ when compiling with clang in c++11 mode
by Marshall Clow 24 Oct '12

24 Oct '12

Has come up again: https://svn.boost.org/trac/boost/ticket/7566#comment I'm thinking that having a clang-c++11 toolset (that includes using libc++) might be a good thing. Any other opinions? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

2 1

Is there a way to specialize how a smart_ptr<T> releases the T?
by David Hagood 24 Oct '12

24 Oct '12

I am trying to wrapper around a C library (specifically, libxml2) so that I can use it within a C++ program. (yes, I am aware of libxml++ - but it doesn't play nice with libxslt). If the core libxml2 objects were internally reference counted, I could use an intrusive_ptr, and have the friend intrusive_ptr_release call libxml2's release function, and all would be well - but unfortunately libxml2 does not internally reference count the objects (at least, not in a way I have seen). If there were a way to specialize smart_ptr<T> such that instead of the destructor calling delete(), it called what I wanted, I'd be set, but I see no way to easily specialize smart_ptr<xmlDoc> in that way - or am I missing something?

8 10

Application using boost libraries (commercial)
by Dominic Amann 24 Oct '12

24 Oct '12

Application: EKKO_Project V1 R1 Company: Sensors & Software Inc, Description: EKKO_Project is the all-inclusive software solution for managing, displaying, processing and interpreting GPR data. It provides easy, highly efficient analysis and integration of GPR data. The software is optimized for Windows 7 and later operating systems. Boost Usage: filesystem, multi-array, smart pointer, date time, iterators, optional, program options, property tree, regex, test, tokenizer, type traits, uBlas. These boost libraries were used extensively in the core program functionality to make a cross-platform library that would allow a thin platform specific GUI to control all basic functionality. URL: <http://sensoft.ca/> Product page: <http://sensoft.ca/Products/Software/Details-Features.aspx#EKKOProject> Thank you, Dominic Amann Software Developer Sensors & Software Inc. 1040 Stacey Court, Mississauga ON. L4W 2X8 Toll Free: 1-800-267-6013 ext. <user ext> T: 905-624-8909 F: 905-624-9365 C: 416-270-4587 E: DAmann(a)sensoft.ca www.sensoft.ca<http://www.sensoft.ca/> subsurface imaging solutions

1 0