You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by "Alberto Massari (JIRA)" <xe...@xml.apache.org> on 2009/12/30 10:09:29 UTC
[jira] Closed: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
change?
[ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alberto Massari closed XERCESC-1903.
------------------------------------
Resolution: Not A Problem
> 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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org