[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)