Created attachment 571202 [details, diff] xmlsec-1.2.27-base64-move-start-of-C-guard-below-includes.patch After upgrade of icu to 64.1, LibreOffice fails to build against xmlsec. The reason seems to be a misplaced ifdef inside /usr/include/xmlsec1/xmlsec/base64.h. >In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/memory:64, > from /usr/include/unicode/localpointer.h:45, > from /usr/include/unicode/uenum.h:23, > from /usr/include/unicode/ucnv.h:53, > from /usr/include/libxml2/libxml/encoding.h:31, > from /usr/include/libxml2/libxml/parser.h:810, > from /usr/include/libxml2/libxml/globals.h:18, > from /usr/include/libxml2/libxml/threads.h:35, > from /usr/include/libxml2/libxml/xmlmemory.h:218, > from /usr/include/libxml2/libxml/tree.h:1307, > from /usr/include/xmlsec1/xmlsec/base64.h:18, > from /var/tmp/portage/app-office/libreoffice-6.2.1.2/work/libreoffice-6.2.1.2/xmlsecurity/inc/xmlsec-wrapper.h:32, > from /var/tmp/portage/app-office/libreoffice-6.2.1.2/work/libreoffice-6.2.1.2/xmlsecurity/source/xmlsec/biginteger.cxx:23: >/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/include/g++-v8/bits/stl_construct.h:72:3: error: template with C linkage > template<typename _T1, typename... _Args> > ^~~~~~~~ The attached patch for xmlsec-1.2.27 is taken from a response to the libreoffice mailing list, and I am currently finishing the rebuild of LO to confirm that this really fixes the issue. I would like to add this patch in an xmlsec-1.2.27-r1 revbump in order to be able to introduce dev-libs/icu-64.1 to tree and bump LO-6.2.2.2 at the same time.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
This is interesting, I do not see any pull request at upstream, and as far as I can see if this is an issue in base64.h then it is common to *all* xmlsec headers, see[1] for example, so I expect much larger fix. There are no actual changes in this file for at least the last 10 years[2]... [1] https://github.com/lsh123/xmlsec/blob/master/include/xmlsec/xmltree.h [2] https://github.com/lsh123/xmlsec/commits/master/include/xmlsec/base64.h
There should be a guard in unicode/utypes.h, need to see why it worked so far and now fails: /** * \def U_SHOW_CPLUSPLUS_API * @internal */ #ifdef __cplusplus # ifndef U_SHOW_CPLUSPLUS_API # define U_SHOW_CPLUSPLUS_API 1 # endif #else # undef U_SHOW_CPLUSPLUS_API # define U_SHOW_CPLUSPLUS_API 0 #endif
no... the guard is the U_NAMESPACE_BEGIN at unicode/uversion.h # define U_NAMESPACE_BEGIN extern "C++" { namespace U_ICU_NAMESPACE {
Problem is in ICU, please see $URL
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=61e590adbee50a9c9b4b96b32b61e24d7140d412 commit 61e590adbee50a9c9b4b96b32b61e24d7140d412 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2019-03-29 22:30:31 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-03-30 09:58:22 +0000 dev-libs/icu: 64.1 version bump Closes: https://bugs.gentoo.org/682032 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> dev-libs/icu/Manifest | 1 + .../icu/files/icu-64.1-guard-memory-include.patch | 52 ++++++++ dev-libs/icu/icu-64.1.ebuild | 143 +++++++++++++++++++++ 3 files changed, 196 insertions(+)
(In reply to Alon Bar-Lev from comment #5) > Problem is in ICU, please see $URL thanks!
I also fixed this at the other side, see[1] [1] https://github.com/lsh123/xmlsec/pull/249
(In reply to Alon Bar-Lev from comment #5) > Problem is in ICU, please see $URL As I said in https://github.com/lsh123/xmlsec/pull/249 and https://unicode-org.atlassian.net/browse/ICU-20530 and https://github.com/unicode-org/icu/pull/572, I think that the problem was only in xmlsec, not in ICU. Could you add revision bump of dev-libs/xmlsec with https://github.com/lsh123/xmlsec/commit/0a14f52e9a5976c104d0fc2d1f739508042aa752 backported?
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #9) > (In reply to Alon Bar-Lev from comment #5) > > Problem is in ICU, please see $URL > > As I said in https://github.com/lsh123/xmlsec/pull/249 and > https://unicode-org.atlassian.net/browse/ICU-20530 and > https://github.com/unicode-org/icu/pull/572, I think that the problem was > only in xmlsec, not in ICU. > > Could you add revision bump of dev-libs/xmlsec with > https://github.com/lsh123/xmlsec/commit/ > 0a14f52e9a5976c104d0fc2d1f739508042aa752 backported? You are making useless noise! And mistake. Please avoid doing any more noise and let me handle the communication with upstream, I fixed an ICU regression for your behalf... you should have found and fixed it yourself... as I invested the time of doing so, please at least don't divert the discussion. It has nothing to do with xmlsec.
A package that worked and introduced C++ class during build of extern "C", then because of a bug fix of *that* package, this stopped working, it is a regression of *that* package. A simple as this. The fact that *a* consumer that we found has friendly upstream and applied *a* "fix" does not mean that *that* package has no regression due to the change in *that* package. Please leave this for upstream to determine its policy and what is the definition of a regression, and avoid additional noise while I communicate. Thanks!
