[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xerces-c-dev
Subject:    [jira] Commented: (XERCESC-1903) xerces-c-3.1.0-rc1: possible API
From:       "Boris Kolpackov (JIRA)" <xerces-c-dev () xml ! apache ! org>
Date:       2009-12-29 19:41:29
Message-ID: 1387866964.1262115689504.JavaMail.jira () brutus ! apache ! org
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/XERCESC-1903?page=com.atlassian.jira.plugi \
n.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-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]