With dev-libs/xerces-c-3.0.0 installed, I get the following error trying to rebuild xalan-c-1.10.0: /var/tmp/portage/dev-libs/xalan-c-1.10.0/work/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:25: error: expected ‘,’ or ‘;’ before ‘namespace’ /var/tmp/portage/dev-libs/xalan-c-1.10.0/work/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:74: error: expected `}' at end of input make[3]: *** [../../../../obj/XalanMsgLib.o] Error 1 make[2]: *** [../../../lib/libxalanMsg.so.110.0] Error 2 make[1]: *** [locale] Error 2
(In reply to comment #0) > With dev-libs/xerces-c-3.0.0 installed, I get the following error trying to > rebuild xalan-c-1.10.0: > > /var/tmp/portage/dev-libs/xalan-c-1.10.0/work/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:25: > error: expected ‘,’ or ‘;’ before ‘namespace’ > /var/tmp/portage/dev-libs/xalan-c-1.10.0/work/xml-xalan/c/src/xalanc/Utils/XalanMsgLib/XalanMsgLib.cpp:74: > error: expected `}' at end of input > make[3]: *** [../../../../obj/XalanMsgLib.o] Error 1 > make[2]: *** [../../../lib/libxalanMsg.so.110.0] Error 2 > make[1]: *** [locale] Error 2 > i confirm this after: emerge @preserved-rebuild
*** Bug 242330 has been marked as a duplicate of this bug. ***
Source of the error seems to be xml-xalan/c/nls/include/LocalMsgData.hpp which starts the initializer for an array called msgArray but doesn't terminate it. LocalMsgData deems to get generated in some way, so this needs to be investigated.
The fix is here: http://svn.apache.org/viewvc?view=rev&revision=696900
Created attachment 168960 [details, diff] Backported r696900 to fix MsgCreator (In reply to comment #4) > The fix is here: http://svn.apache.org/viewvc?view=rev&revision=696900 Nice. Doesn't apply out of the box, though, so I ported the patch to the 1.10.0 sources used by Gentoo. Fixing the issue with the messages only leads to the next compile time error: src/xalanc/PlatformSupport/AttributesImpl.cpp:168: error: cannot declare variable ‘theTempList’ to be of abstract type ‘xalanc_1_10::AttributesImpl’
Yeah, judging by the comments in the revision log we'll need a few more of those changes for things to work.
The xalan-c trunk compiles with xerces-c-3.0.0. We have the following options: a) Backport all necessary changes b) Provide a snapshot of Xalan-C (dev-libs/xalan-c.1.10.1_pre20081020) I contacted upstream to see whether they have something to say about it.
(In reply to comment #7) > a) Backport all necessary changes I'm currently in the process of doing so. So far I identified these changesets: http://svn.apache.org/viewvc?view=rev&revision=482425 http://svn.apache.org/viewvc?view=rev&revision=572759 http://svn.apache.org/viewvc?view=rev&revision=651671 http://svn.apache.org/viewvc?view=rev&revision=672824 http://svn.apache.org/viewvc?view=rev&revision=696900 For these I've resolved conflicts, but it still doesn't compile. Will work on that a bit more, but won't make any promises. > b) Provide a snapshot of Xalan-C (dev-libs/xalan-c.1.10.1_pre20081020) http://thread.gmane.org/gmane.text.xml.xalan.c++.user/3600/focus=3601 tells us that a new release, to be numbered 1.11, is currently under way, and furthermore that current HEAD is considered stable enough for testing. > I contacted upstream to see whether they have something to say about it. Where have you posted?
Created attachment 169168 [details, diff] Backported 7 changesets to make things compile This patch is a backport of the following changesets: http://svn.apache.org/viewvc?view=rev&revision=482425 http://svn.apache.org/viewvc?view=rev&revision=572759 http://svn.apache.org/viewvc?view=rev&revision=651671 http://svn.apache.org/viewvc?view=rev&revision=671671 http://svn.apache.org/viewvc?view=rev&revision=672824 http://svn.apache.org/viewvc?view=rev&revision=672963 http://svn.apache.org/viewvc?view=rev&revision=696900 With this patch in place (instead of the one submitted previously) xalan-c-1.10.0 compiled all right against xerces-c-3.0.0. Still untested so far. Given the fact that we are currently blocking a security issue, and therefore want to stabilize things as soon as possible, we might go for this patch for a 1.10.0-r1 (or maybe even without revbump) to start stabilizing now, and an svn snapshot as 1.11 prerelease for testing. It would also be interesting to find out whether packages depending on xalan-c, like app-emulation/virtualbox-ose or www-apps/Embperl, would need to be recompiled after the patch. If so, a soname change would probably be nice, so that portage could preserve the libs until the depending packages are rebuilt. version.incl seems the place to do so. Finding a version between the old 110 for 1.10 and an assumed new 111 for 1.11 might be difficult. Which reminds me to check the version.incl from upstream trunk, and realize that in fact it is still configured for 1.10: http://svn.apache.org/viewvc/xalan/c/trunk/version.incl?view=markup I somehow doubt that the interface is binary compatible across those versions. Would someone care to check this with upstream?
I directly contacted the (as it seems) only active upstream dev :-) Here's the relevant part from his answer: [...] > How far away is the next Xalan-C release? What will be the version > number? (so we can name the snapshot X_pre20081020 for example). > Do you already provide a compatibility patch? I'm working on a new release right now, which will be 1.11. I'm not sure how long it will take for me to get everything together, but it will be at least 3-4 weeks. I'm trying to get the trunk stabilized within a couple of weeks, but it depends on the state of some of the more obscure ports (Mingw comes to mind as one of them). I could also provide a patch for Xalan-C 1.10, but it would be quite a bit of work, due to the API changes in Xerces-C. Do you have a particular deadline for Gentoo? [...] The problem is this: Patching the already stable xalan-c is a no go since it will break compilation with xerces-c <3.0.0. So, my proposal is to rev-bump it using the changes and let the arch-teams mark the rev-bump stable together with xerces-c-3.0.0. I really don't like such a big patch, do we really want this or do we want a snapshot of the trunk? halcy0n, griffon26, your opinion? Could anybody already test whether other packages depending on xerces-c and/or xalan-c are broken?
(In reply to comment #10) > The problem is this: Patching the already stable xalan-c is a no go since it > will break compilation with xerces-c <3.0.0. Are you sure about this? I haven't gone over all the changes myself, but they seem to fall into three categories: 1. Providing implementations for new purely virtual methods. For old xerces those would be methods not overridden but newly introduced by xalan, but there is nothing wrong with this. 2. Introducing some new typedefs, with preprocessor switches based on XERCES_VERSION_MAJOR. Especially these type dependency seems to me at least an attempt at working with xalan-c 2.7. 3. Changing signatures to make use of the new typedefs from 2. So I'd expect at least a fair chance of things compiling against xerces 2.7 as well. Only source code compatible, of course, not binary compatible. If not, we could have patch enclose all changes in preprocessor switches, or simply have the ebuild only apply the patch when compiling against xerces 3. On the other hand, as it is xerces 2 which has the security issues, I wouldn't worry too much about that compatibility, and a synchroneous stabilization sounds like a good plan to me.
Whether we go with a big patch or with a snapshot of trunk, I think we have about the same chance that it is broken. At least in the latter case the effort to get there is much less. And if anything in trunk is broken, the patches that we make can be sent upstream. In the case of the big patch it would likely require some more digging through the repository because the patch was incomplete, which is useless effort.
As user I would prefer the trunk snapshot solution and I completely agree with Maurice van der Pot in comment #12.
hit by this very problem here too.
Created attachment 169716 [details, diff] Changes from 1.10.0 to xalan-c-1.11.0_pre705082.ebuild OK, I just tried a snapshot against r705082 from 2008-10-16. That version seems to include the latest compatibility fixes, while the few commits between then and now seem more feature-related. Compiles nicely here, without the Gentoo-specific patches. Getting rid of the -O2 compiler flag introduced by runConfigure in order to have the user's CFLAGS take precedence required an additional substitution, but this would affect 1.10.0 as well. Included in this diff. Steps I used to create the svn snapshot tarball: $ mkdir xml-xalan $ svn export -r 705082 http://svn.apache.org/repos/asf/xalan/c/trunk \ xml-xalan/c $ tar czf Xalan-C_r705082-src.tar.gz xml-xalan $ rm -r xml-xalan The tarball should be placed on the Gentoo mirrors. Comparing the set of installed files to that from 1.10.0, ignoring documentation: +/usr/include/xalanc/PlatformSupport/ProblemListenerBase.hpp -/usr/include/xalanc/PlatformSupport/Resettable.hpp -/usr/include/xalanc/XMLSupport/FormatterToDOM.hpp -/usr/include/xalanc/XPath/XNull.hpp -/usr/include/xalanc/XPath/XSpan.hpp +/usr/include/xalanc/XSLT/XalanParamHolder.hpp No soname change yet, but I guess I'd wait for 1.11 for that change, even if that might risk something to break.
Ok, thanks a lot for the analysis, Martin. I'll see that I come up with a revised ebuild (it sucks the way it is now) and do the version bump on Monday (no internet at home).
(In reply to comment #16) > Ok, thanks a lot for the analysis, Martin. > I'll see that I come up with a revised ebuild (it sucks the way it is now) and > do the version bump on Monday (no internet at home). > Thanks Tiziano. I'll make an EAPI=0 version of xerces-c and try to deal with the other fallout.
*** Bug 246386 has been marked as a duplicate of this bug. ***
Archs, please test and mark xalan-c-1.11.0_pre705082 stable. This is a short testing cycle since there is a security bug that depends on this going stable so we don't break stable.
Sparc stable.
amd64 and x86 marked this stable, so resolving.
