[jira] [Commented] (XERCESC-2257) symbol not found in flat namespace (_xercesc_messages_3_2_dat)
"Scott Cantor (Jira)" <[email protected]> Thu, 14 Nov 2024 19:56:00 +0000 (UTC)
| Newsgroups | gmane.text.xml.xerces-c.devel |
|---|---|
| Message-ID | <[email protected]> |
[ https://issues.apache.org/jira/browse/XERCESC-2257?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D17=
898407#comment-17898407 ]=20
Scott Cantor commented on XERCESC-2257:
---------------------------------------
There is no official statement about it, every time it comes up, the PMC de=
cides to leave the project in limbo and the board hasn't stepped in. It is =
what it is, and I just don't think it's responsible to portray the situatio=
n externally as other than it is when an issue arises such as the port stat=
us. I didn't intend to open a can of worms, but none of this is new informa=
tion or anything that wasn't true 5 years ago, and if deprecating the port =
starts a conversation outside of the ASF, then that's a clear positive in m=
y mind.
All of this applies equally to xml-security-c except that that PMC didn't f=
ight the move to retire the code base, so there's no ambiguity there.
If the PMC agrees to change the public status of the project, then I will p=
ost whatever is agreed to, but as it stands, I have no license to do that. =
I probably had no claim to say what I did about the port, but the facts and=
the public position aren't really in alignment here.
I don't happen to agree that it's the project's job to explicitly reach out=
to dependent projects. It's the responsbility of any project that depends =
on anything to be actively monitoring and aware of the state of its depende=
ncies, not the other way around. I have been very public on the lists about=
all this, so the only people who don't know the situation didn't pay any a=
ttention.
To your questions, I don't know anything about xml-commons at all. I assume=
d Xerces-P died years ago but I don't know that for a fact, I don't really =
know much about it either.
Xerces-J was even more moribund than this version was but was revived a bit=
recently (unwisely IMHO) so it's in a slightly better state I suppose but =
that was after years of neglect. As a personal opinion, I do think one woul=
d be ill-advised to be using it at this point also, particularly given that=
the fork in the JDK exists.
> 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:
> =C2=A0
> {noformat}
> dyld[5155]: symbol not found in flat namespace (_xercesc_messages_3_2_dat=
)
> {noformat}
> =C2=A0
> This was reported to MacPorts here: [https://trac.macports.org/ticket/713=
04]
> 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/MsgLoade=
rs/ICU/ICUMsgLoader.cpp#L54-L55]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)