[serialization] BOOST_NO_EXCEPTIONS bug
Hi, KDE folks has reported that trying to use Boost with exceptions turned off results in duplicate symbol error from Boost.Serialization, like so: kdevclassbrowser. dir/allclassesfolder.o: In function `boost::serialization::throw_exception(std::exception const&)': /usr/include/boost/serialization/throw_exception.hpp:29: multiple definition of `boost::serialization::throw_exception(std::exception const&)' The reason is missing inline, which the attached patch fixes? Robert, is this OK for trunk & release branches? - Volodya
First of all, I should say I'm really embarassed to find such an idiotic oversight on my part. I've got no problem in seeing this checked into the trunk. However, I don't think checking in a change directly into the release branch is a great idea. This file is included by anything in the library that throws an exception. Without comprehensive testing, it's impossible to know that there will be no unexpected repercussions. These repercussions could hold up the release of ALL libraries for 1.39. On the other hand, we know the repercussions of letting this slide to the next release. One (very important) user will have to patch his local copy until the next release. I think the best is to check it into the trunk and let it migrate into the release using the normal procedure. Robert Ramey Vladimir Prus wrote:
Hi,
KDE folks has reported that trying to use Boost with exceptions turned off results in duplicate symbol error from Boost.Serialization, like so:
kdevclassbrowser. dir/allclassesfolder.o: In function `boost::serialization::throw_exception(std::exception const&)': /usr/include/boost/serialization/throw_exception.hpp:29: multiple definition of `boost::serialization::throw_exception(std::exception const&)'
The reason is missing inline, which the attached patch fixes? Robert, is this OK for trunk & release branches?
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
First of all, I should say I'm really embarassed to find such an idiotic oversight on my part.
I've got no problem in seeing this checked into the trunk. However, I don't think checking in a change directly into the release branch is a great idea. This file is included by anything in the library that throws an exception. Without comprehensive testing, it's impossible to know that there will be no unexpected repercussions. These repercussions could hold up the release of ALL libraries for 1.39.
I don't think this is likely -- given that no tests are run with BOOST_NO_EXCEPTIONS defined, so even if some compilers, upon seeing the "inline" keyword, immediately die, this won't cause regression tests on release branch to die.
On the other hand, we know the repercussions of letting this slide to the next release. One (very important) user will have to patch his local copy until the next release.
I think the best is to check it into the trunk and let it migrate into the release using the normal procedure.
You mean, after seeing that nothing breaks? The release branch is open until 20th, so we have the time. Should I commit to trunk? - Volodya
On Tue, Apr 14, 2009 at 11:29 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
given that no tests are run with BOOST_NO_EXCEPTIONS defined
boost::throw_exception is tested with BOOST_NO_EXCEPTIONS. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Tue, Apr 14, 2009 at 11:29 AM, Vladimir Prus <vladimir@codesourcery.com> wrote:
given that no tests are run with BOOST_NO_EXCEPTIONS defined
boost::throw_exception is tested with BOOST_NO_EXCEPTIONS.
This is a boost::serialization change and I talked about boost::serialization tests. - Volodya
commit to the turnk. Robert Ramey Vladimir Prus wrote:
Robert Ramey wrote:
First of all, I should say I'm really embarassed to find such an idiotic oversight on my part.
I've got no problem in seeing this checked into the trunk. However, I don't think checking in a change directly into the release branch is a great idea. This file is included by anything in the library that throws an exception. Without comprehensive testing, it's impossible to know that there will be no unexpected repercussions. These repercussions could hold up the release of ALL libraries for 1.39.
I don't think this is likely -- given that no tests are run with BOOST_NO_EXCEPTIONS defined, so even if some compilers, upon seeing the "inline" keyword, immediately die, this won't cause regression tests on release branch to die.
On the other hand, we know the repercussions of letting this slide to the next release. One (very important) user will have to patch his local copy until the next release.
I think the best is to check it into the trunk and let it migrate into the release using the normal procedure.
You mean, after seeing that nothing breaks? The release branch is open until 20th, so we have the time. Should I commit to trunk?
- Volodya
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (4)
-
Emil Dotchevski -
Robert Ramey -
Vladimir Prus -
Vladimir Prus