Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=168960) [details]
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 an attachment (id=169168) [details]
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 an attachment (id=169716) [details]
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.