[
https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12795119#action_12795119
]
Boris Kolpackov commented on XERCESC-1903:
------------------------------------------
We can also ask the XQilla folks to release 2.2.3 or some such to resolve this
once 3.1.0 is out.
> xerces-c-3.1.0-rc1: possible API change?
> ----------------------------------------
>
> Key: XERCESC-1903
> URL: https://issues.apache.org/jira/browse/XERCESC-1903
> Project: Xerces-C++
> Issue Type: Bug
> Affects Versions: 3.1.0
> Environment: debian
> Reporter: Jay Berkenbilt
>
> A debian user reports trouble compiling xqilla 2.2.2
> (http://xqilla.sourceforge.net) with xerces-c 3.1.0 rc1 but says that it does
> compile with 3.0.1. We exchanged a few messages, but neither one of us is
> sure whether the code in question is using an internal interface that is not
> supposed to be part of the public API or whether this is an unintentional API
> incompatibility. I'm including the text of our latest email exchange here so
> you can make a judgment call on this before the final 3.1.0 is released.
> ======================
> >> I was compiling XQilla library version 2.2.2 from
> >> http://xqilla.sourceforge.net against Xerces-C in Debian, when I noticed
> >> that the xqilla library cannot be compiled against libxerces-c-dev
> >> 3.1.0~rc1, but it can compiled against version 3.0.1 still in testing.
> >> So it seems that version 3.1 breaks API compatibility. Are you and/or
> >> upstream developers aware of this? Is this actually a bug that I should
> >> report against libxerces-c-dev or not?
> >
> > I'm not aware of any expected API changes between 3.0.1 and 3.1.0, but I
> > haven't checked with upstream. I believe the intention is not to
> > introduce API compatibilities though. Please go ahead and file a bug
> > against the debian package. Obviously any specific details you can
> > provide would be helpful. I will then forward it to upstream. Thanks
> > for bringing this to my attention!
> Hi,
> I looked now the error messages a bit more to see what was changed, and
> noticed that those API breaks are in a class definition in the subdir
> "internal". Thus I now wonder if it counts as API break that would in
> the interest of the developers. Here is the compiler error I got:
> src/schema/SchemaValidatorFilter.cpp: In member function 'virtual unsigned
> int SchemaValidatorFilter::resolveQName(const XMLCh*,
> xercesc_3_1::XMLBuffer&, short int, int&)':
> src/schema/SchemaValidatorFilter.cpp:713: error: no matching function for
> call to 'xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh [],
> xercesc_3_1::ElemStack::MapModes, bool&)'
> /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are:
> unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool&) const
> src/schema/SchemaValidatorFilter.cpp:729: error: no matching function for
> call to 'xercesc_3_1::ElemStack::mapPrefixToURI(XMLCh*,
> xercesc_3_1::ElemStack::MapModes, bool&)'
> /usr/include/xercesc/internal/ElemStack.hpp:190: note: candidates are:
> unsigned int xercesc_3_1::ElemStack::mapPrefixToURI(const XMLCh*, bool&) const
> --
> Tommi Vainikainen
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
