boost-1.51.0 introduces some changes which contain methods with unused parameters. This will fail g++ when using very pedantic settings. Precisely: https://svn.boost.org/trac/boost/ticket/7049 which has been already fixed in https://svn.boost.org/trac/boost/changeset/79477 4 months ago. As I depend on boost *and* on these compiler settings I can no longer work with my Gentoo machine, since it renders: <pre> ... [ 36%] Building CXX object bin/CMakeFiles/backmeup-gui.dir/controller/register_state.cpp.o In file included from /usr/include/boost-1_51/boost/program_options/options_description.hpp:12:0, from /usr/include/boost-1_51/boost/program_options.hpp:15, from /home/dyle/doc/src/ait/backmeup/native-client/baseinc.h:52, from /home/dyle/doc/src/ait/backmeup/native-client/bin/controller/register_state.cpp:18: /usr/include/boost-1_51/boost/program_options/errors.hpp:253:22: error: unused parameter ‘option_name’ [-Werror=unused-parameter] ... </pre> in my projects now. Worse. I cannot change back to a good working boost-1.49 because this will introduce a downgrade of glibc and this yields: * Sanity check to keep you from breaking your system: * Downgrading glibc is not supported and a sure way to destruction * ERROR: sys-libs/glibc-2.15-r3 failed (setup phase): * aborting to save your system Yeah! My system turned into a good working, save brick. I'm stuck and my system is lost. :( What should I do. Changing the compiler settings for my projects is not an option, since I'm not alone and this will have an impact for all project members. For the simple reason, Gentoo gives me a bogus boost at hand. ... and yes, I've seen it in the "Current Stable Release" from www.boost.org. What can I do? Reproducible: Always Actual Results: Breaks compilage on system with pedantic C++ flags. Expected Results: Should compile fine even with pedeantic C++ flags (as 1.49. did). For me this is very serious because this blocks me in using Gentoo as a developer machine.
They just released 1.52, let's see if it's fixed there. But in general, -Werror is not supported by Gentoo so next time you should be a bit less "ranty" about it.
Hm, sorry, don't want to be offensive. However, the problem is, that I got stuck with the current setup. -Werror is not supported by Gentoo, that's fine. And that boost-1.51 does not work for me is fine too. Usually I switch back to versions, I'm fond of. So, as I got aware of this situation I wanted to go back to boost-1.49. And, yes, I've read your blog http://blog.flameeyes.eu/2012/07/boosting-my-morale-i-wish ... but I thought to myself "naaaa... icebergs ahead, but they'll sure have it going, like always". But - bad luck - I already switched due to a world-update to glibc-2.16 *and* boost-1.51. boost-1.49 depends on <glibc-2.16 (you know better than me). Having this explicit sanity check when downgrading glibc makes my flesh grow. So, in order to have boost-1.49 again, I have to badass-downgrade glibc ... uhm ... which I would like to avoid. So, honestly, what are my chances? Should I really kick glibc-2.16 and go down to glibc-2.15.x again? What is the risk? boost-1.52 is marked as beta at boost.org. I assume some bugs are solved, some new are introduced. I really would appreciate a boost-1.51.1 with the bug fixed. And live happily ever after with glibc-2.16. Wishful thinking. Hm, I may provide a patch doing this.
I'm currently testing on my local (reduced) test rig for boost-1.52. Then I'll commit it under p.mask and start the real testing. I might just do a 1.51.0-r2 as there is at least another bug (the RWX sections) which has to be addressed and might be better fixed before 1.52 ...
(Also, you should be able to override your local cmake build to use -Wno-error=unused-parameter even if you can't change the upstream project.)
(In reply to comment #4) > (Also, you should be able to override your local cmake build to use > -Wno-error=unused-parameter even if you can't change the upstream project.) Oh, I did that. But this yields now plenty of warnings, which later on are treated as no-go in our build-chain. See, the goal is at least: no errors, no warnings. Also, having a patch for a Gentoo boost-1.51 does not work either, since some Devs are running Ubuntu, some plain Debian ... *sigh*. It ain't easy. -.-
Uhm, what do you mean a local patch to boost won't work? If the problem is that the other distros are also moving to Boost 1.51, yes the only solution is to get a new update from upstream.. I'm afraid I can't really help you much with that, Also the "no error, no warning" is useful... sometimes. Not always, in this case it might be worth to ignore those warnings — unfortunately boost uses -I instead of -isystem as otherwise the latter would already hide them.
Yes, I just draw the very same conclusion. Fact is, I'm the first one who encountered boost-1.51 within the team. I detected that this version is no good so I'm going back to the working one 1.49. But I can't go back without breaking some things. I guess, that's why they call it "bleeding" edge. Just cut myself. I've got the gain some knowledge about why boost-1.49 depends on <glib-2.16.
Because TIME_UTC is now a C library constant and boost-1.49 counts it as an enum. Boost 1.50 changes that to TIME_UTC_ — breaking the API, so we can't backport that change at all.
Ah ... found another way - with less, less headache. I'll just # ifdef HAVE_BOOST_LIB # include <boost/version.hpp> # include <boost/algorithm/string.hpp> # include <boost/crc.hpp> # include <boost/filesystem.hpp> # include <boost/format.hpp> // fix for boost 1.51: this boost version has some poor programming quality # if __GNUC__ == 4 && __GNUC_MINOR__ >= 6 && BOOST_VERSION == 105100 # pragma GCC diagnostic push # pragma GCC diagnostic ignored "-Wunused-parameter" # include <boost/program_options.hpp> # pragma GCC diagnostic pop # else # include <boost/program_options.hpp> # endif # include <boost/program_options/detail/config_file.hpp> # include <boost/range.hpp> # include <boost/tokenizer.hpp> # endif in my projects. And it is fine. Done. So, for me the ticket can be closed. Am I to close it?
This should be fixed with 1.52 .. and if it's not it's something for upstream to fix anyway.
