I'm trying to build Libreoffice using clang++ and libc++ on Linux. libc++ itself uses LLVM's libc++abi as the ABI library. The problem arises because Libreoffice code tries to use __cxa_exception, which isn't made public in libc++abi, leading to build failure. /home/armin/src/libreoffice-5.1.0.3/bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx:144:17: error: no type named '__cxa_exception' in namespace '__cxxabiv1' __cxxabiv1::__cxa_exception * header, uno_Any *, uno_Mapping * pCpp2Uno ); ~~~~~~~~~~~~^ /home/armin/src/libreoffice-5.1.0.3/bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx:84:5: error: use of undeclared identifier '__cxa_exception'; did you mean '__cxa_free_exception'? Is there a way libreoffice can move from this code to a more generic one?
See also https://llvm.org/bugs/show_bug.cgi?id=26562
Bugzilla isn't the right place for build related issues. Please ask this on the dev mailing list.
This isn't a build issue, it's a toolchain incompatibility that requires porting from the libreoffice side.
(In reply to Armin K from comment #0) > Is there a way libreoffice can move from this code to a more generic one? No, see <https://llvm.org/bugs/show_bug.cgi?id=26562#c12>.
Created attachment 122544 [details] RFC Patch to get libcxxabi build going on Before posting to the reviewboard, I'd like to ask here if something like this is acceptable. First of all, I had to copy some code from libsupc++ cxxabi.h, which was already done earlier for __class_type_info and __si_class_type_info. I assume that's okay, since nobody brought up any issues against that in the past. Secondly, I had to copy some code from LLVM's libunwind and libcxxabi repositories, to get the same code which is there for libstdc++ just down below in the patched file. Now, I am not really familiar with the licensing terms, but LLVM's license is more permissive than GCC's, thus I'm wondering if it might be incompatible with libreoffice code, or if I need to do something else to fullfill it. See [1] and [2]. And at last, I'm a bit worried about the redefined types (__*_type_info), which are available in the libcxxabi runtime (although unsure if visible outside), so I must ask if anyone knows will redefining such types (which are implemented way different in libcxxabi) create a potential issue at runtime? That's all for now. [1] https://opensource.org/licenses/UoI-NCSA.php [2] http://llvm.org/docs/DeveloperPolicy.html#license
And, after several hours, I can confirm that with this patch, libreoffice builds and runs just fine when built with clang++ using libc++/libc++abi as the stdlib. Lets hope I didn't break any other setup.
With final comment I'm closing as WFM - in the future I suggest going immediately to the developer mailing list with these kinds of issues as you'll get *much better response*.
Closing this issue before the patch has landed was a mistake. I was going to reference this issue in the review request.
(In reply to Armin K from comment #5) [cannot give advice on the licensing questions] > And at last, I'm a bit worried about the redefined types (__*_type_info), > which are available in the libcxxabi runtime (although unsure if visible > outside), so I must ask if anyone knows will redefining such types (which > are implemented way different in libcxxabi) create a potential issue at > runtime? Should probably be OK; all three __*_type_info structs have non-inline virtual dtors.
(In reply to Armin K from comment #8) > Closing this issue before the patch has landed was a mistake. I was going to > reference this issue in the review request. Setting to NEW, to avoid confusion.
On master with my recent commits leading up to <https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=49f81b3f33e1b043a1615855503768d78db5f093>, building on Linux x86-64 with clang -stdlib=libc++ (using libc++abi) works for me (at least with a trunk Clang build towards Clang 3.9). Please reopen if you still run into problems in bridges/source/cpp_uno/gcc3_linux_x86-64.
Thank you for fixing this. Is there any chance to backport this to 5.1?
(In reply to Armin K from comment #12) > Is there any chance to backport this to 5.1? Why do you need it there?
(In reply to Stephan Bergmann from comment #13) > (In reply to Armin K from comment #12) > > Is there any chance to backport this to 5.1? > > Why do you need it there? To include it in a released version as soon as possible. I'm guessing changes in current git master won't be released anytime soon.
(In reply to Armin K from comment #14) > To include it in a released version as soon as possible. I'm guessing To rephrase differently, then: What is your demand for LO 5.1 on Linux built against libc++/libc++abi? > changes in current git master won't be released anytime soon. Current master will get released as LO 5.2, <https://wiki.documentfoundation.org/ReleasePlan/5.2>. That said, it should probably be possible to backport the > 1e161eb Use config_cxxabi.h to check for __*class_type_info > 3d63d0c Adapt __cxxabiv1 for libc++abi > 0fef230 Declarations based on config_cxxabi.h should be unrelated to _LIBCPP_VERSION > 069506b Use config_cxxabi.h to check for __cxa_eh_globals, __cxa_exception > 128deea cxxabi.h is not specific to GCC > baad027 Expect _Unwind_Exception to be defined in the compilers' unwind.h patchset to -5-1, but I would at least want to wait for confirmation at <https://gerrit.libreoffice.org/#/c/9722/> "Fix build on FreeBSD with libc++" that it doesn't break that.
(In reply to Stephan Bergmann from comment #15) > (In reply to Armin K from comment #14) > > To include it in a released version as soon as possible. I'm guessing > > To rephrase differently, then: What is your demand for LO 5.1 on Linux > built against libc++/libc++abi? > I don't demand the official packages to be built with clang++ / libc++. I am just using a source based distribution and doing my best to avoid using g++ and libstdc++ (just for fun). However, when almost everything is built against one C++ std lib, you can't just link other stuff built by different compiler that's using different std lib (g++ / libstdc++) with libraries built by clang++ / libc++ due to different library namespace. That gave me an option: Build libreoffice with clang++ / libc++ or relink the libraries libreoffice uses (and with that, half of the system back) with g++ / libstdc++. Now, about merging the patches to 5.1 branch. In doing so, they can get back to me and other people using clang++ / libc++ / libc++abi combination early for testing and having need to backport things ourself. Of course, that wouldn't be a big problem either (everyone wants to do less work themself). > > changes in current git master won't be released anytime soon. > > Current master will get released as LO 5.2, > <https://wiki.documentfoundation.org/ReleasePlan/5.2>. > I already saw that, which is why I said "anytime soon" (almost half a year from today). > That said, it should probably be possible to backport the > > > 1e161eb Use config_cxxabi.h to check for __*class_type_info > > 3d63d0c Adapt __cxxabiv1 for libc++abi > > 0fef230 Declarations based on config_cxxabi.h should be unrelated to _LIBCPP_VERSION > > 069506b Use config_cxxabi.h to check for __cxa_eh_globals, __cxa_exception > > 128deea cxxabi.h is not specific to GCC > > baad027 Expect _Unwind_Exception to be defined in the compilers' unwind.h > > patchset to -5-1, but I would at least want to wait for confirmation at > <https://gerrit.libreoffice.org/#/c/9722/> "Fix build on FreeBSD with > libc++" that it doesn't break that. Okay. Thank you again for fixing this.