|
Posted
about 1 year
ago
by
Scott Cantor
My recollection FWIW regarding the ports...I thought a Xerces port predated me adding xml-security-c and the Shibboleth stack ports to the tree. I don't know if there was an active maintainer, but I think my impression is/was that I kind of stepped Read more
|
|
Posted
about 1 year
ago
by
Scott Cantor
There is no official statement about it, every time it comes up, the PMC decides 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 situation externally as other Read more
|
|
Posted
about 1 year
ago
by
Ryan Carsten Schmidt
If your intent is to abandon xerces-c in the future, I think it would be advantageous to communicate with the projects currently relying on xerces-c so that they can take appropriate steps. The possibilities, once you stop maintaining xerces-c, seem Read more
|
|
Posted
about 1 year
ago
by
Scott Cantor
The issue is maintaining it. We got stuck with a CMake build system I can't maintain because of that, and I should have pushed back harder. There was a CI link set up for the project by that same person (not via GitHub I don't think) but I don't know Read more
|
|
Posted
about 1 year
ago
by
Ryan Carsten Schmidt
symbol not found in flat namespace (_xercesc_messages_3_2_dat)
|
|
Posted
about 1 year
ago
by
Ryan Carsten Schmidt
Software linking with libxerces-c-3.3.dylib fails to work: dyld[5155]: symbol not found in flat namespace (_xercesc_messages_3_2_dat)
This was reported to MacPorts here: https://trac.macports.org/ticket/71304 This is a regression; 3.2.4 Read more
|
|
Posted
about 1 year
ago
by
Florian Wiesner
Change enum tokType (util/regx/Token.hpp) member names
|
|
Posted
about 1 year
ago
by
Florian Wiesner
the current enumeration uses T_CHAR, T_STRING, etc. as enumeration values. Those symbol names are generic enough to cause clashes with other libraries - where T_CHAR, T_STRING, etc. are used as macros/definitions. Minimum improvement would be to Read more
|
|
Posted
about 1 year
ago
by
Florian Wiesner
the current enumeration uses T_CHAR, T_STRING, etc. as enumeration values. Those symbol names are generic enough to cause clashes with other libraries - espe. Therefore, a change to C++11 scoped enums would fix this potential for clashes on the side Read more
|
|
Posted
about 1 year
ago
by
Florian Wiesner
the current enumeration uses T_CHAR, T_STRING, etc. as enumeration values. Those symbol names are generic enough to cause clashes with other libraries. Therefore, a change to C++11 scoped enums would fix this potential for clashes on the side of Read more
|