[
https://issues.apache.org/jira/browse/XERCESC-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17898497#comment-17898497
]
Boris Kolpackov commented on XERCESC-2257:
------------------------------------------
Let me add a couple of clarifications:
> I am the last maintainer left, [...], and once I'm fully off Xerces in a few
> years, I seriously doubt it has a future unless somethiing changes.
As I said many times before, we have a product that depends on Xerces-C++ (XSD)
and we will pick up fixing critical issues (which we already sometimes do) and
cutting the releases once you stop doing that. I appreciate all your work on
Xerces-C++, especially going through the brain-dead release process, but please
stop spreading FUD about Xerces-C++. Yes, it has bugs and even security issues,
but I think it has been demonstrated in the past that the critical ones will be
fixed, maybe not promptly enough for everyone to be happy, but they will. I
don't understand your urge to kill Xerces-C++ because you are moving off it,
please just let it be. Other people depend on it and they have no alternatives
to move to. So just let me know when you want to retire from cutting the
releases and I will make a plan to take over.
> The issue is specific to the ICU build, which is not getting tested by anyone
> gating releases at this point, that's why it slipped through.
Again, this is more nuanced than that: there are two places where Xerces-C++
can optionally use ICU: to do character conversions (transcoder) and to load
localized diagnostics messages (message loader). Pretty much every major Linux
distribution builds Xerces-C++ with ICU for the former. Plus we test Xerces-C++
(before and after the release) with ICU transcoder in our CI:
[https://cppget.org/?builds=libxerces-c&pc=transcoder-icu|https://cppget.org/?builds=libxerces-c&pv=&th=*&tg=&tc=&pc=transcoder-icu&rs=*]
for every major platform and compiler. But it's true that the latter (ICU for
message loader) is not widely used or tested (which is what this bug is about).
> Can CI be added?
I agree with Scott here that it should only be added if the author commits to
maintaining it long-term. We've had CI contributions in the past where the
author naturally looses interest and the thing goes rotten and causes more work
to other maintainers. Having said that, I would be prepared to add build2
support to Xerces-C++ and setup our CI (i.e., the link above) which I will then
maintain.
BTW, these types of discussions should really be happening on the mailing list
and not the issues tracker.
> symbol not found in flat namespace (_xercesc_messages_3_2_dat)
> --------------------------------------------------------------
>
> Key: XERCESC-2257
> URL: https://issues.apache.org/jira/browse/XERCESC-2257
> Project: Xerces-C++
> Issue Type: Bug
> Affects Versions: 3.3.0
> Reporter: Ryan Carsten Schmidt
> Priority: Major
>
> Software linking with libxerces-c-3.3.dylib fails to work:
>
> {noformat}
> dyld[5155]: symbol not found in flat namespace (_xercesc_messages_3_2_dat)
> {noformat}
>
> This was reported to MacPorts here: [https://trac.macports.org/ticket/71304]
> This is a regression; 3.2.4 didn't have this problem.
> Surely for version 3.3.x on these lines {{3_2}} should be changed to
> {{{}3_3{}}}?
> [https://github.com/apache/xerces-c/blob/v3.3.0/src/xercesc/util/MsgLoaders/ICU/ICUMsgLoader.cpp#L54-L55]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
