GNOME Bugzilla – Bug 757042
fails to build on armel
Last modified: 2015-10-30 10:23:20 UTC
Version: 2.40.0 The latest version of libxml++2.6 fails to build on armel: https://buildd.debian.org/status/package.php?p=libxml%2B%2B2.6&suite=sid Full build log at https://buildd.debian.org/status/fetch.php?pkg=libxml%2B%2B2.6&arch=armel&ver=2.40.0-1&stamp=1444323767
Here is the error from that log: libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I.. -I/usr/include/libxml2 -I/usr/include/glibmm-2.4 -I/usr/lib/arm-linux-gnueabi/glibmm-2.4/include -I/usr/include/glib-2.0 -I/usr/lib/arm-linux-gnueabi/glib-2.0/include -I/usr/include/sigc++-2.0 -I/usr/lib/arm-linux-gnueabi/sigc++-2.0/include -DLIBXMLPP_BUILD -D_FORTIFY_SOURCE=2 -Wall -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -std=c++11 -c exceptions/wrapped_exception.cc -fPIC -DPIC -o exceptions/.libs/wrapped_exception.o In file included from exceptions/wrapped_exception.cc:18:0: exceptions/wrapped_exception.h:43:49: error: expected ‘)’ before ‘exception_ptr’ explicit wrapped_exception(std::exception_ptr exception_ptr); ^ exceptions/wrapped_exception.h:50:8: error: ‘exception_ptr’ in namespace ‘std’ does not name a type std::exception_ptr exception_ptr_;
Line 43 is this line explicit wrapped_exception(std::exception_ptr exception_ptr); here: class wrapped_exception : public exception { public: explicit wrapped_exception(std::exception_ptr exception_ptr); ~wrapped_exception() noexcept override; It looks like std::exception_ptr isn't defined, for some reason: http://en.cppreference.com/w/cpp/error/exception_ptr and this seems to be a known g++ problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58938 I guess we need to check for it at configure time and #ifdef around it.
Created attachment 314088 [details] [review] Patch
I'll have a closer look at this later (hopefully today). The basic idea is good, but I think some details can be made nicer. The lack of std::exception_ptr is even more of a nuisance in libxml++ 2.91.1. I've used it even more there, and it simplified the exception handling. Now I will have to revert most of that simplification. Lucky that libxml++ 3.0.x has not been released yet.
Created attachment 314144 [details] [review] patch: Add LIBXMLXX_HAVE_EXCEPTION_PTR I've split the patch into two. This is the first one. Both patches are intended for the libxml++-2-40 branch, but this one can probably be applied also to the master branch with no or minimal modification. This is like similar config tests in other packages. The test code is stored in build/cxx_std.m4.
Created attachment 314145 [details] [review] patch: Work around some platforms' lack of support for std::exception_ptr This is the second patch. Most of it is identical to Daniel's patch. The most important difference is Parser::handle_exception() and Validator:: handle_exception(). The rather long list of catch clauses can be kept just in those two methods. It simplifies especially SaxParser. The same trick is used in Glib::exception_handlers_invoke() and Glib::glibmm_unexpected_ exception(): Call a method from many exception handlers, and re-throw the exception. config.h is not installed. It can be included in test programs. In header files that application programs can include, use libxml++config.h. I would be great to have these patches tested in a system without std::exception_ptr. I've tested it by fiddling with the config test program in cxx_std.m4, to make it fail, but that's not quite the same as a test on a system without std::exception_ptr.
s/I would be great/It would be great/
Hi Kjell, I do have access to armel porter boxes, so I can give the patches a try. Thanks for the quick response everyone!
Seems to build fine on armel now. Test-suite passes as well. Didn't do any more elaborate checks.
Created attachment 314151 [details] build log on armel with the two patches applied
Thanks for the quick test! I'll give Daniel a chance to comment. (It was his patch that I modified quite a bit.) Then I'll push the patches and make a 2.40.1 release.
Hi Kjell, I think your changes look good. I like that you created an Autoconf macro to test for std::exception_ptr support. Also, I learned something new about exception handling in C++ (namely that you can call a handler function within the catch block and the exception object remains valid until the exception is handled). Your refactoring to contain the list of catch blocks to a single handler, thus eliminating duplicated code, is an excellent idea. One possible issue: Does adding the handle_exception() member to `xmlpp::Parser' and `xmlpp::Validator' technically break ABI compatibility in this case? The new member is declared within a block of protected members. C++98 specifies layout compatibility for POD-struct types, but seemingly nothing else. The latest C++ working draft, n4527, now talks about "standard-layout class" types, but `xmlpp::Parser' and `xmlpp::Validator' are non-standard-layout types because of the virtual functions.
> One possible issue: Does adding the handle_exception() member to > `xmlpp::Parser' and `xmlpp::Validator' technically break ABI compatibility in > this case? We add non-virtual methods to classes all the time in other packages, such as gtkmm, trying to keep up with changes in the underlying C package. It has been done before in libxml++ too. I would be surprised if it would cause a problem in this case. There are some restrictions, though: Don't add virtual methods, don't add data members, don't add base classes.
I have pushed the patches in comments 5 and 6, plus a patch that adds a short description of the exception handling to the documentation of SaxParser. Those patches were added to the libxml++-2-40 branch. It remains to make similar changes to the master branch. I leave this bug open until that's fixed. What about a 2.40.1 release? Shall I do that right away, or wait for more problems to be detected and fixed?
A 2.40.1 release sounds great. Should new problems turn up, we can always release a 2.40.1.1 or 2.40.2.
Perhaps there is a minor problem with the new handle_exception() methods after all. I'm still convinced that they don't break ABI, but I don't know if all protected methods are considered API. New API is not allowed between 2.40.0 and 2.40.1. I've pushed a patch that makes handle_exception() private. Then they are certainly not part of the API.
< I don't know if all protected methods are considered API. Yes, protected methods are API, because builds would break if those methods were used and the methods then disappeared. > New API is not allowed between 2.40.0 and 2.40.1. Ideally, not, yes. > I've pushed a patch that makes handle_exception() private. Then they are > certainly not part of the API. Would it be particularly useful as API? If so, we can make it protected for 2.42. Thanks.
I have released libxml++ 2.40.1. > Would it be particularly useful as API? I doubt that. > If so, we can make it protected for 2.42. If there will ever be a 2.42 release. Most of future development will be on 3.x, I hope. Anyway, there are protected handle_exception() methods in 2.91.1 in the master branch. I will have to modify them now. They can't use std::exception_ptr unconditionally.
https://buildd.debian.org/status/package.php?p=libxml%2B%2B2.6&suite=sid Looking good. Closing this bug report. Thanks everyone.
https://buildd.debian.org/status/logs.php?pkg=libxml%2B%2B2.6&ver=2.40.1-1 that's the link specific for version 2.40.1
Now I've updated the master branch, too. Perhaps time for another new release? 2.91.2 or 2.93.1 or what? ABI is not identical to 2.91.1. Luckily the ABI of libxml++-3.0. has not been frozen yet.
Sure.
I have released libxml++ 2.91.2.