[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch 0002-cmake-Check-for-char16_t.patch 0003-autoconf-Check-for-char16_t.patch 0004-tests-Add-Char16Test.patch Add unit test to demonstrate this works. > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, > 0004-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2104) Add automake unit tests to match cmake tests
[ https://issues.apache.org/jira/browse/XERCESC-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2104. -- Resolution: Fixed Assignee: Roger Leigh Fix Version/s: 3.2.0 Fixed. The automake and cmake unit tests now use the same test data. > Add automake unit tests to match cmake tests > > > Key: XERCESC-2104 > URL: https://issues.apache.org/jira/browse/XERCESC-2104 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.2.0 > Reporter: Roger Leigh >Assignee: Roger Leigh > Labels: automake, test-suite > Fix For: 3.2.0 > > Attachments: > 0001-cmake-Add-test-corrections-to-align-with-sanityTest-.patch, > 0002-Add-individual-automake-checks.patch, > 0003-automake-Use-silent-rules-in-place-of-custom-logic.patch > > > The attached patches replace the sanityTest perl script with a set of small > scripts which allow the automake test-runner to run the unit tests > individually, as for cmake, including individual logs containing diffs where > there are errors. > It also replaces some of the custom boilerplate in the Makefile.ams with > AM_SILENT_RULES, which does the same thing now it's directly supported in > automake (for a long time now, so all recent automake versions will support > it in practice). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2104) Add automake unit tests to match cmake tests
[ https://issues.apache.org/jira/browse/XERCESC-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16083782#comment-16083782 ] Roger Leigh commented on XERCESC-2104: -- Committed to svn. This makes the automake unit tests green again. > Add automake unit tests to match cmake tests > > > Key: XERCESC-2104 > URL: https://issues.apache.org/jira/browse/XERCESC-2104 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: automake, test-suite > Attachments: > 0001-cmake-Add-test-corrections-to-align-with-sanityTest-.patch, > 0002-Add-individual-automake-checks.patch, > 0003-automake-Use-silent-rules-in-place-of-custom-logic.patch > > > The attached patches replace the sanityTest perl script with a set of small > scripts which allow the automake test-runner to run the unit tests > individually, as for cmake, including individual logs containing diffs where > there are errors. > It also replaces some of the custom boilerplate in the Makefile.ams with > AM_SILENT_RULES, which does the same thing now it's directly supported in > automake (for a long time now, so all recent automake versions will support > it in practice). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch 0003-cmake-Check-for-char16_t.patch 0004-autoconf-Check-for-char16_t.patch 0005-tests-Add-Char16Test.patch Final patch set with support for all platforms and a unit test. > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0003-autoconf-Check-for-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0004-tests-Add-Char16Test.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0002-cmake-Check-for-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082206#comment-16082206 ] Roger Leigh commented on XERCESC-2101: -- I might also write a C++11-specific unit test to exercise the direct use of u"" strings, but the code that's here should be ready to commit if you're happy with it. > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland >Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, > char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2035) Add Windows build configs with static MSVC CRT linkage
[ https://issues.apache.org/jira/browse/XERCESC-2035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082217#comment-16082217 ] Roger Leigh commented on XERCESC-2035: -- You can certainly do this by tweaking the various {{CMAKE_CXX_FLAGS_*}} variables to change them from their defaults. We leave them as the defaults since using the non-static runtimes is recommended and most people will want that. But there's nothing to stop an end user from tweaking these when running cmake; either by passing in {{-DCMAKE_CXX_FLAGS_XXX=...}} on the command-line or by editing the script. Newer cmake versions let you set the "Platform Toolset" on top of this. It's not something I've played with much; I've generally stuck to the defaults unless I had a good reason to change things. > Add Windows build configs with static MSVC CRT linkage > -- > > Key: XERCESC-2035 > URL: https://issues.apache.org/jira/browse/XERCESC-2035 > Project: Xerces-C++ > Issue Type: Improvement > Components: Miscellaneous >Affects Versions: 3.1.0, 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: All >Reporter: Lee Doron >Priority: Minor > Fix For: 3.2.0 > > > The Windows DLL builds (e.g. Debug and Release) currently are linked against > the Microsoft Visual C++ C Runtime DLLs (using the /MDd and /MD options, > respectively). This means that it cannot function without the corresponding > MSVCRnnn.DLL file, so the end user must install the proper Microsoft Visual > C++ Redistributable. > Please consider adding build configurations that are statically linked to the > CRT (almost identical to those above, but using the /MTd and /MT options, > respectively). This would give developers the option of using a Xerces DLL > that doesn't have this dependency on the Redistributable package. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2048) Error during build on Windows/MinGW because of LDFLAGS=-no-undefined
[ https://issues.apache.org/jira/browse/XERCESC-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16082861#comment-16082861 ] Roger Leigh commented on XERCESC-2048: -- Looks like a libtool issue, and it's certainly working with CMake. I haven't tested with current libtool/autoconf, but it may well also be functional. I don't have the time to dedicate to mingw support either; making it build was about the limit of what I can manage. > Error during build on Windows/MinGW because of LDFLAGS=-no-undefined > - > > Key: XERCESC-2048 > URL: https://issues.apache.org/jira/browse/XERCESC-2048 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.2, 3.1.3 > Environment: Windows 8.1 with MinGW >Reporter: Philip Young >Priority: Blocker > Fix For: 3.2.0 > > > Followed the build instructions and used ./configure LDFLAGS=-no-undefined > config.log shows the following: > Target: mingw32 > Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 > --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld > --enable-lto --enable-libssp --disable-multilib > --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions > --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug > --enable-version-specific-runtime-libs > --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld > --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= > --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp > --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw > --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T > Thread model: win32 > gcc version 4.8.1 (GCC) > configure:3781: $? = 0 > configure:3770: g++ -V >&5 > g++.exe: error: unrecognized command line option '-V' > g++.exe: fatal error: no input files > compilation terminated. > configure:3781: $? = 1 > configure:3770: g++ -qversion >&5 > g++.exe: error: unrecognized command line option '-qversion' > g++.exe: fatal error: no input files > compilation terminated. > configure:3781: $? = 1 > configure:3801: checking whether the C++ compiler works > configure:3823: g++ -no-undefined conftest.cpp >&5 > g++.exe: error: unrecognized command line option '-no-undefined' > configure:3827: $? = 1 > configure:3865: result: no > configure: failed program was: > | /* confdefs.h */ -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16069093#comment-16069093 ] Roger Leigh commented on XERCESC-2077: -- Hi Franz, You're most welcome, and I'm glad that the work is useful and appreciated! If you have any suggestions on improving it, or run into any problems, don't hesitate to get in touch. Kind regards, Roger > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Fix For: 3.2.0 > > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, > cmake_bcb5_err.zip, screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstr
[jira] [Created] (XERCESC-2104) Add automake unit tests to match cmake tests
Roger Leigh created XERCESC-2104: Summary: Add automake unit tests to match cmake tests Key: XERCESC-2104 URL: https://issues.apache.org/jira/browse/XERCESC-2104 Project: Xerces-C++ Issue Type: Improvement Components: Build Affects Versions: 3.2.0 Reporter: Roger Leigh Attachments: 0001-cmake-Add-test-corrections-to-align-with-sanityTest-.patch, 0002-Add-individual-automake-checks.patch, 0003-automake-Use-silent-rules-in-place-of-custom-logic.patch The attached patches replace the sanityTest perl script with a set of small scripts which allow the automake test-runner to run the unit tests individually, as for cmake, including individual logs containing diffs where there are errors. It also replaces some of the custom boilerplate in the Makefile.ams with AM_SILENT_RULES, which does the same thing now it's directly supported in automake (for a long time now, so all recent automake versions will support it in practice). -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[ https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072477#comment-16072477 ] Roger Leigh commented on XERCESC-2088: -- [~canto...@osu.edu] I tried out the patch, but {{xercesc/dom/impl/DOMNodeBase.hpp}} is missing from the patch contents. > Bad casting from DOMTextImpl to DOMElementImpl > -- > > Key: XERCESC-2088 > URL: https://issues.apache.org/jira/browse/XERCESC-2088 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @ > 3.40GHz, 16GB >Reporter: Yuseok Jeon >Assignee: Scott Cantor > Fix For: 3.2.0 > > Attachments: Actual_result.txt, casting.patch, relationship_tree.jpeg > > > Hi all, > Our recently developed type confusion detection tool reports a type_confusion > error in the "xercesc/dom/imple/DOMCasts.hpp" > xercesc/dom/imple/DOMCasts.hpp, line 146 > static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p) > { > DOMElementImpl *pE = (DOMElementImpl *)p; > return &(pE->fNode); > } > p is pointing to the object allocated as DOMTextImpl, and it is casted into > DOMElementImpl. However, since DOMElementImpl is not a subobject of > DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is > undefined if the object that the pointer to be casted points to is not a > suboject of down casting type) and causes undefined behaviors. > There are similar type-confusion cases as below links. > - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 > - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280 > I attached a actual type confusion report and object relationship > information. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2088) Bad casting from DOMTextImpl to DOMElementImpl
[ https://issues.apache.org/jira/browse/XERCESC-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16072780#comment-16072780 ] Roger Leigh commented on XERCESC-2088: -- Tested in [this branch|https://github.com/rleigh-codelibre/xerces-c/commits/casting-2088]. Green in [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/249694130] [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.104]. Looks good. I was having odd segfaults with FreeBSD and xalan last year, and I would not be at all surprised if some of this was at fault. Making it conforming should be a big improvement. > Bad casting from DOMTextImpl to DOMElementImpl > -- > > Key: XERCESC-2088 > URL: https://issues.apache.org/jira/browse/XERCESC-2088 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.1.1, 3.1.2, 3.1.3, 3.1.4 > Environment: ubuntu 16.04 LTS, Intel(R) Core(TM) i7-6700 CPU @ > 3.40GHz, 16GB >Reporter: Yuseok Jeon >Assignee: Scott Cantor > Fix For: 3.2.0 > > Attachments: Actual_result.txt, casting.patch, DOMNodeBase.hpp, > relationship_tree.jpeg > > > Hi all, > Our recently developed type confusion detection tool reports a type_confusion > error in the "xercesc/dom/imple/DOMCasts.hpp" > xercesc/dom/imple/DOMCasts.hpp, line 146 > static inline DOMNodeImpl *castToNodeImpl(const DOMNode *p) > { > DOMElementImpl *pE = (DOMElementImpl *)p; > return &(pE->fNode); > } > p is pointing to the object allocated as DOMTextImpl, and it is casted into > DOMElementImpl. However, since DOMElementImpl is not a subobject of > DOMTextImpl, it is violating C++ standard rules 5.2.9/11 (down casting is > undefined if the object that the pointer to be casted points to is not a > suboject of down casting type) and causes undefined behaviors. > There are similar type-confusion cases as below links. > - (libstdc++) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60734 > - (Firefox) https://bugzilla.mozilla.org/show_bug.cgi?id=1074280 > I attached a actual type confusion report and object relationship > information. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2077: - Attachment: 0001-cmake-Add-CMake-build-system-trunk.patch Patch after rebasing onto trunk. The only changes were fixing three minor conflicts in Makefile.am EXTRA_DIST. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xerces was linked with, i.e. transitive dependencies. > - Installs the HTML documentation > - Targets are provided for regenerating the docu
[jira] [Commented] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15983441#comment-15983441 ] Roger Leigh commented on XERCESC-2077: -- Now rebased onto trunk. I'm looking at re-running our test CI jobs on the new branch to verify it's working the same as the older patch for 3.1, but given that there are zero changes I don't expect any problems--it passed all the tests on the platform I tested it on by hand. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xer
[jira] [Created] (XERCESC-2109) Build failure on FreeBSD with CMake
Roger Leigh created XERCESC-2109: Summary: Build failure on FreeBSD with CMake Key: XERCESC-2109 URL: https://issues.apache.org/jira/browse/XERCESC-2109 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.0 Environment: FreeBSD 11.1 with clang 4.0.0 Reporter: Roger Leigh Assignee: Roger Leigh {{{ 19:20:26 cd /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src && /usr/bin/CC -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS -I/usr/local/include -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src -isystem /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC -pthread -std=gnu++14 -o CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp 19:20:26 /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: error: use of undeclared identifier 'XERCES_SIZE_MAX' 19:20:26 else if (XERCES_SIZE_MAX - inputLength < 2) { 19:20:26 ^ 19:20:26 1 error generated. }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2111) Build failure with Windows and VS2013
[ https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2111: - Affects Version/s: 3.2.0 > Build failure with Windows and VS2013 > - > > Key: XERCESC-2111 > URL: https://issues.apache.org/jira/browse/XERCESC-2111 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Windows Server 2008R2 with Visual Studio 2013 >Reporter: Roger Leigh > > snprintf isn't available before VS2015, though a Microsoft-specific variant > is available which we could use conditionally. However, even this is not > present in earlier Visual Studio releases. Do we strictly need to use > snprintf here? If we do, how far back do our Visual Studio portability > requirements go? > {{{ > 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe /nologo /TP > -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I. > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src > -Isrc > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include > /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes > /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj > /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480) > : error C3861: 'snprintf': identifier not found > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2111) Build failure with Windows and VS2013
Roger Leigh created XERCESC-2111: Summary: Build failure with Windows and VS2013 Key: XERCESC-2111 URL: https://issues.apache.org/jira/browse/XERCESC-2111 Project: Xerces-C++ Issue Type: Bug Components: Build Environment: Windows Server 2008R2 with Visual Studio 2013 Reporter: Roger Leigh snprintf isn't available before VS2015, though a Microsoft-specific variant is available which we could use conditionally. However, even this is not present in earlier Visual Studio releases. Do we strictly need to use snprintf here? If we do, how far back do our Visual Studio portability requirements go? {{{ 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe /nologo /TP -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS -I. -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src -Isrc -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp 17:53:44 D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned long', possible loss of data 17:53:44 D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned long', possible loss of data 17:53:44 D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned long', possible loss of data 17:53:44 D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477) : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned long', possible loss of data 17:53:44 D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480) : error C3861: 'snprintf': identifier not found }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2110) Build failure on FreeBSD with Autoconf
[ https://issues.apache.org/jira/browse/XERCESC-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115321#comment-16115321 ] Roger Leigh commented on XERCESC-2110: -- This is due to HAVE_TIMEGM being missing from the config.h.cmake.in header. Are there any other potentially missing values? > Build failure on FreeBSD with Autoconf > -- > > Key: XERCESC-2110 > URL: https://issues.apache.org/jira/browse/XERCESC-2110 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: FreeBSD 11.1 with clang 4.0.0 >Reporter: Roger Leigh > > Looks like illegal arithmetic with time_t? > {{{ > make all-am > CXX xercesc/util/XMLDateTime.lo > ../../xerces-c-3.2.0/src/xercesc/util/XMLDateTime.cpp:571:27: error: invalid > operands to binary expression ('time_t' (aka 'long') and 'char *(*)(int, > int)') > return mktime() - timezone; >~~ ^ > 1 error generated. > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2110) Build failure on FreeBSD with Autoconf
Roger Leigh created XERCESC-2110: Summary: Build failure on FreeBSD with Autoconf Key: XERCESC-2110 URL: https://issues.apache.org/jira/browse/XERCESC-2110 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.0 Environment: FreeBSD 11.1 with clang 4.0.0 Reporter: Roger Leigh Looks like illegal arithmetic with time_t? {{{ make all-am CXX xercesc/util/XMLDateTime.lo ../../xerces-c-3.2.0/src/xercesc/util/XMLDateTime.cpp:571:27: error: invalid operands to binary expression ('time_t' (aka 'long') and 'char *(*)(int, int)') return mktime() - timezone; ~~ ^ 1 error generated. }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2110) Build failure on FreeBSD with Autoconf
[ https://issues.apache.org/jira/browse/XERCESC-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16115330#comment-16115330 ] Roger Leigh commented on XERCESC-2110: -- Potential fix here: https://github.com/rleigh-codelibre/xerces-c/commits/timegm > Build failure on FreeBSD with Autoconf > -- > > Key: XERCESC-2110 > URL: https://issues.apache.org/jira/browse/XERCESC-2110 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: FreeBSD 11.1 with clang 4.0.0 >Reporter: Roger Leigh > > Looks like illegal arithmetic with time_t? > {{{ > make all-am > CXX xercesc/util/XMLDateTime.lo > ../../xerces-c-3.2.0/src/xercesc/util/XMLDateTime.cpp:571:27: error: invalid > operands to binary expression ('time_t' (aka 'long') and 'char *(*)(int, > int)') > return mktime() - timezone; >~~ ^ > 1 error generated. > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16106268#comment-16106268 ] Roger Leigh commented on XERCESC-2101: -- Regarding being from scratch, it's about as different a reimplementation as I could make it while still retaining the same functional effect. Unnecessary parts like the config header changes for windows were dropped outright. Some parts can't be reimplemented differently and so are the same out of necessity; what's in the patch 0001 is mostly just the addition of reinterpret_cast for wchar_t*, and there's very little freedom to be creative there--I've used reinterpret_cast in place of C style casts wherever possible. > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0003-cmake-Check-for-char16_t.patch, > 0004-autoconf-Check-for-char16_t.patch, > 0004-autoconf-Check-for-char16_t.patch, 0005-tests-Add-Char16Test.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch 0003-cmake-Check-for-char16_t.patch 0004-autoconf-Check-for-char16_t.patch 0005-tests-Add-Char16Test.patch In the absence of a response, I've rewritten the patch myself in the interest of getting this in. Builds passed in https://travis-ci.org/rleigh-codelibre/xerces-c/builds/258621587 and https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.116 Would this be OK to merge? > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0003-cmake-Check-for-char16_t.patch, > 0004-autoconf-Check-for-char16_t.patch, > 0004-autoconf-Check-for-char16_t.patch, 0005-tests-Add-Char16Test.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0003-cmake-Check-for-char16_t.patch, > 0004-autoconf-Check-for-char16_t.patch, > 0004-autoconf-Check-for-char16_t.patch, 0005-tests-Add-Char16Test.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0003-cmake-Check-for-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0005-tests-Add-Char16Test.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0004-autoconf-Check-for-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland > Assignee: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-Add-MacOS-X-support-for-XERCES_XMLCH_T-char16_t.patch, > 0003-cmake-Check-for-char16_t.patch, 0004-autoconf-Check-for-char16_t.patch, > 0005-tests-Add-Char16Test.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2113) Base64.cpp missing config.h include
Roger Leigh created XERCESC-2113: Summary: Base64.cpp missing config.h include Key: XERCESC-2113 URL: https://issues.apache.org/jira/browse/XERCESC-2113 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 3.2.0 Reporter: Roger Leigh {{{ 13:04:43 /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: error: use of undeclared identifier 'XERCES_SIZE_MAX' 13:04:43 else if (XERCES_SIZE_MAX - inputLength < 2) { 13:04:43 ^ }}} I think this is because of a missing stdint.h include. This is provided by config.h, but there's no config.h include in Base64.cpp. Other platforms must be getting this via an indirect include. Note that this also has other portability implications (though they don't need tackling right now). Using size_t implies using SIZE_MAX, but SIZE_MAX requires stdint.h. stdint.h was previously optional, with fallbacks used if not present, but this makes it effectively mandatory, making all of the other integer portability logic redundant. i.e. we could just require stdint.h/cstdint unconditionally and drop all of the other logic. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2113) Base64.cpp missing config.h include
[ https://issues.apache.org/jira/browse/XERCESC-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2113: - Component/s: Build > Base64.cpp missing config.h include > --- > > Key: XERCESC-2113 > URL: https://issues.apache.org/jira/browse/XERCESC-2113 > Project: Xerces-C++ > Issue Type: Bug > Components: Build, Utilities >Affects Versions: 3.2.0 > Reporter: Roger Leigh > > {{{ > 13:04:43 > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: > error: use of undeclared identifier 'XERCES_SIZE_MAX' > 13:04:43 else if (XERCES_SIZE_MAX - inputLength < 2) { > 13:04:43 ^ > }}} > I think this is because of a missing stdint.h include. This is provided by > config.h, but there's no config.h include in Base64.cpp. Other platforms > must be getting this via an indirect include. > Note that this also has other portability implications (though they don't > need tackling right now). Using size_t implies using SIZE_MAX, but SIZE_MAX > requires stdint.h. stdint.h was previously optional, with fallbacks used if > not present, but this makes it effectively mandatory, making all of the other > integer portability logic redundant. i.e. we could just require > stdint.h/cstdint unconditionally and drop all of the other logic. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Closed] (XERCESC-2113) Base64.cpp missing config.h include
[ https://issues.apache.org/jira/browse/XERCESC-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh closed XERCESC-2113. Resolution: Invalid This one is a bit strange. Building xerces in isolation, everything is working fine. This is working: cd /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xt2/src && /usr/bin/CC -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS -isystem /usr/local/include -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xt2 -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xt2/src -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC -pthread -std=gnu++14 -o CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp This is failing: cd /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src && /usr/bin/CC -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS -I/usr/local/include -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src -isystem /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC -pthread -std=gnu++14 -o CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: error: use of undeclared identifier 'XERCES_SIZE_MAX' else if (XERCES_SIZE_MAX - inputLength < 2) { ^ 1 error generated. It's all down to using -I/usr/local/include and not -isystem /usr/local/include which is a bit odd. If I update Base64.cpp to include config.h, I get a warning about /usr/local/include/xercesc/util/Xerces_autoconf_config.hpp:65:9: warning: 'XERCES_XMLCH_T' macro redefined [-Wmacro-redefined] but it all works. But it then fails with [ 1%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/BinInputStream.cpp.o /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/BinInputStream.cpp:48:30: error: out-of-line definition of 'getEncoding' does not match any declaration in 'xercesc_3_1::BinInputStream' const XMLCh* BinInputStream::getEncoding() const ^~~ I think what's happening here is that the xerces 3.1 headers in /usr/local are being included in preference to those in the source tree. This is definitely not a xerces problem; it's my problem, so I'll close this. > Base64.cpp missing config.h include > --- > > Key: XERCESC-2113 > URL: https://issues.apache.org/jira/browse/XERCESC-2113 > Project: Xerces-C++ > Issue Type: Bug > Components: Build, Utilities >Affects Versions: 3.2.0 >Reporter: Roger Leigh > > {{{ > 13:04:43 > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: > error: use of undeclared identifier 'XERCES_SIZE_MAX' > 13:04:43 else if (XERCES_SIZE_MAX - inputLength < 2) { > 13:04:43 ^ > }}} > I think this is because of a missing stdint.h include. This is provided by > config.h, but there's no config.h include in Base64.cpp. Other platforms > must be getting this via an indirect include. > No
[jira] [Created] (XERCESC-2114) Link failure with Xalan-C
Roger Leigh created XERCESC-2114: Summary: Link failure with Xalan-C Key: XERCESC-2114 URL: https://issues.apache.org/jira/browse/XERCESC-2114 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.0 Environment: VS2013 on Windows Server 2012R2 Reporter: Roger Leigh Testing latest rc1 with xalan and VS2013: [Build log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console] Using [this patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff] to build Xalan with VS2013 (it's just the upgraded project files). {noformat} 12:29:32(Link target) -> 12:29:32 XalanDiagnosticMemoryManager.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) unsigned __int64 const `public: static unsigned __int64 __cdecl xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned __int64)'::`2'::alignment" (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB) [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj] 12:29:32 ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : fatal error LNK1120: 1 unresolved externals [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj] {noformat} Is there any incompatible change expected here? Could potentially be missing symbol exports or anything of that nature? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2114) Link failure with Xalan-C
[ https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16118558#comment-16118558 ] Roger Leigh commented on XERCESC-2114: -- It may well be Xalan to blame, and I'll try to find time to investigate this more closely tomorrow. I don't imagine that the exports are faulty because all the unit tests and samples work perfectly. > Link failure with Xalan-C > - > > Key: XERCESC-2114 > URL: https://issues.apache.org/jira/browse/XERCESC-2114 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: VS2013 on Windows Server 2012R2 >Reporter: Roger Leigh > > Testing latest rc1 with xalan and VS2013: > [Build > log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console] > Using [this > patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff] > to build Xalan with VS2013 (it's just the upgraded project files). > {noformat} > 12:29:32(Link target) -> > 12:29:32 XalanDiagnosticMemoryManager.obj : error LNK2001: > unresolved external symbol "__declspec(dllimport) unsigned __int64 const > `public: static unsigned __int64 __cdecl > xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned > __int64)'::`2'::alignment" > (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB) > > [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj] > 12:29:32 ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : > fatal error LNK1120: 1 unresolved externals > [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj] > {noformat} > Is there any incompatible change expected here? Could potentially be missing > symbol exports or anything of that nature? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2110) Build failure on FreeBSD with Autoconf
[ https://issues.apache.org/jira/browse/XERCESC-2110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2110. -- Resolution: Fixed Fix Version/s: 3.2.0 Also fixed by the config.h inclusion added in #2110. > Build failure on FreeBSD with Autoconf > -- > > Key: XERCESC-2110 > URL: https://issues.apache.org/jira/browse/XERCESC-2110 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: FreeBSD 11.1 with clang 4.0.0 >Reporter: Roger Leigh >Assignee: Roger Leigh > Fix For: 3.2.0 > > > Looks like illegal arithmetic with time_t? > {{{ > make all-am > CXX xercesc/util/XMLDateTime.lo > ../../xerces-c-3.2.0/src/xercesc/util/XMLDateTime.cpp:571:27: error: invalid > operands to binary expression ('time_t' (aka 'long') and 'char *(*)(int, > int)') > return mktime() - timezone; >~~ ^ > 1 error generated. > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2109) Build failure on FreeBSD with CMake
[ https://issues.apache.org/jira/browse/XERCESC-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2109. -- Resolution: Fixed Fixed in r1804297. > Build failure on FreeBSD with CMake > --- > > Key: XERCESC-2109 > URL: https://issues.apache.org/jira/browse/XERCESC-2109 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: FreeBSD 11.1 with clang 4.0.0 >Reporter: Roger Leigh >Assignee: Roger Leigh > Fix For: 3.2.0 > > > {{{ > 19:20:26 cd > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src > && /usr/bin/CC -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I/usr/local/include > -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build > > -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src > > -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src > -isystem > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include > -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 > -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long > -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder > -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros > -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC -pthread -std=gnu++14 -o > CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp > 19:20:26 > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: > error: use of undeclared identifier 'XERCES_SIZE_MAX' > 19:20:26 else if (XERCES_SIZE_MAX - inputLength < 2) { > 19:20:26 ^ > 19:20:26 1 error generated. > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2109) Build failure on FreeBSD with CMake
[ https://issues.apache.org/jira/browse/XERCESC-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116293#comment-16116293 ] Roger Leigh commented on XERCESC-2109: -- Fixed in r1804297. There were two problems here. One was that CMake requires updates to config.h.cmake.in (there's no direct equivalent to autoheader, unfortunately--I could probably write one). The second was that config.h wasn't included in XMLDateTime.cpp, so it was failing anyway on any platform where the fallback failed. > Build failure on FreeBSD with CMake > --- > > Key: XERCESC-2109 > URL: https://issues.apache.org/jira/browse/XERCESC-2109 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: FreeBSD 11.1 with clang 4.0.0 >Reporter: Roger Leigh >Assignee: Roger Leigh > Fix For: 3.2.0 > > > {{{ > 19:20:26 cd > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src > && /usr/bin/CC -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I/usr/local/include > -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build > > -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src > > -I/opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-build/src > -isystem > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/stage/include > -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 > -Wimplicit-atomic-properties -Wmissing-declarations -Wno-long-long > -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder > -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros > -fstrict-aliasing -msse2 -O3 -DNDEBUG -fPIC -pthread -std=gnu++14 -o > CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.o -c > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp > 19:20:26 > /opt/hudson/workspace/OME-FILES-CPP-DEV-merge-superbuild/BUILD_TYPE/Release/node/brill/build/xerces-source/src/xercesc/util/Base64.cpp:149:14: > error: use of undeclared identifier 'XERCES_SIZE_MAX' > 19:20:26 else if (XERCES_SIZE_MAX - inputLength < 2) { > 19:20:26 ^ > 19:20:26 1 error generated. > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2111) Build failure with Windows and VS2013
[ https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116681#comment-16116681 ] Roger Leigh commented on XERCESC-2111: -- Also note https://stackoverflow.com/questions/2915672/snprintf-and-visual-studio-2010 We use this in libtiff like so: https://github.com/vadz/libtiff/blob/master/port/snprintf.c and this CMake logic: https://github.com/vadz/libtiff/blob/master/port/CMakeLists.txt#L42 and this autoconf logic: https://github.com/vadz/libtiff/blob/master/configure.ac#L429 I could look at implementing this in Xerces if you like. > Build failure with Windows and VS2013 > - > > Key: XERCESC-2111 > URL: https://issues.apache.org/jira/browse/XERCESC-2111 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Windows Server 2008R2 with Visual Studio 2013 >Reporter: Roger Leigh >Assignee: Scott Cantor > Fix For: 3.2.0 > > > snprintf isn't available before VS2015, though a Microsoft-specific variant > is available which we could use conditionally. However, even this is not > present in earlier Visual Studio releases. Do we strictly need to use > snprintf here? If we do, how far back do our Visual Studio portability > requirements go? > {{{ > 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe /nologo /TP > -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I. > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src > -Isrc > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include > /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes > /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj > /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480) > : error C3861: 'snprintf': identifier not found > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Comment Edited] (XERCESC-2111) Build failure with Windows and VS2013
[ https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116725#comment-16116725 ] Roger Leigh edited comment on XERCESC-2111 at 8/7/17 3:15 PM: -- I would personally be fine with STL and ostringstream or equivalent. At worst, it increases the compile time of a few files slightly. It's more portable than snprintf given Microsoft's previous lack of support for C and C99, so would be an obvious safe replacement. I use them all the time without trouble, and you can even imbue streams with locales for more control over serialisation should we care about e.g. stable number formatting etc. was (Author: rleigh): I would personally be fine with STL and ostringstream or equivalent. At worst, it increases the compile time of a few files slightly. It's more portable than snprintf given Microsoft's previous lack of support for C and C99, so would be an obvious safe replacement. I use them all the time without trouble, and you can even imbue streams with locales for more control over serialisation should be care about e.g. stable number formatting etc. > Build failure with Windows and VS2013 > - > > Key: XERCESC-2111 > URL: https://issues.apache.org/jira/browse/XERCESC-2111 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Windows Server 2008R2 with Visual Studio 2013 >Reporter: Roger Leigh >Assignee: Scott Cantor > Fix For: 3.2.0 > > > snprintf isn't available before VS2015, though a Microsoft-specific variant > is available which we could use conditionally. However, even this is not > present in earlier Visual Studio releases. Do we strictly need to use > snprintf here? If we do, how far back do our Visual Studio portability > requirements go? > {{{ > 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe /nologo /TP > -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I. > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src > -Isrc > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include > /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes > /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj > /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480) > : error C3861: 'snprintf': identifier not found > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2111) Build failure with Windows and VS2013
[ https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116725#comment-16116725 ] Roger Leigh commented on XERCESC-2111: -- I would personally be fine with STL and ostringstream or equivalent. At worst, it increases the compile time of a few files slightly. It's more portable than snprintf given Microsoft's previous lack of support for C and C99, so would be an obvious safe replacement. I use them all the time without trouble, and you can even imbue streams with locales for more control over serialisation should be care about e.g. stable number formatting etc. > Build failure with Windows and VS2013 > - > > Key: XERCESC-2111 > URL: https://issues.apache.org/jira/browse/XERCESC-2111 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Windows Server 2008R2 with Visual Studio 2013 >Reporter: Roger Leigh >Assignee: Scott Cantor > Fix For: 3.2.0 > > > snprintf isn't available before VS2015, though a Microsoft-specific variant > is available which we could use conditionally. However, even this is not > present in earlier Visual Studio releases. Do we strictly need to use > snprintf here? If we do, how far back do our Visual Studio portability > requirements go? > {{{ > 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe /nologo /TP > -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I. > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src > -Isrc > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include > /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes > /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj > /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480) > : error C3861: 'snprintf': identifier not found > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2111) Build failure with Windows and VS2013
[ https://issues.apache.org/jira/browse/XERCESC-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16116773#comment-16116773 ] Roger Leigh commented on XERCESC-2111: -- I've tested with VS2013 and the sprintf workaround is working fine (just a compiler warning), so I think this is fine as it is for 3.2.0, but we could look at sstream for the future if using the STL is allowed (I'd still like to use standard exceptions, but probably too late for 3.2.x at this point). > Build failure with Windows and VS2013 > - > > Key: XERCESC-2111 > URL: https://issues.apache.org/jira/browse/XERCESC-2111 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Windows Server 2008R2 with Visual Studio 2013 >Reporter: Roger Leigh >Assignee: Scott Cantor > Fix For: 3.2.0 > > > snprintf isn't available before VS2015, though a Microsoft-specific variant > is available which we could use conditionally. However, even this is not > present in earlier Visual Studio releases. Do we strictly need to use > snprintf here? If we do, how far back do our Visual Studio portability > requirements go? > {{{ > 17:53:44 FAILED: C:\PROGRA~2\MICROS~3.0\VC\bin\amd64\cl.exe /nologo /TP > -DHAVE_CONFIG_H=1 -DXERCES_BUILDING_LIBRARY=1 > -DXERCES_DLL_NAME=\"xerces-c_3_2.dll\0\" -D_THREAD_SAFE=1 -Dxerces_c_EXPORTS > -I. > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src > -Isrc > -ID:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\stage\include > /DWIN32 /D_WINDOWS /W3 /GR /EHsc /W3 /MD /O2 /Ob2 /DNDEBUG /showIncludes > /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\XMLDateTime.cpp.obj > /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(471) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(473) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(475) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(477) > : warning C4244: 'initializing' : conversion from 'time_t' to 'unsigned > long', possible loss of data > 17:53:44 > D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xerces-source\src\xercesc\util\XMLDateTime.cpp(480) > : error C3861: 'snprintf': identifier not found > }}} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2077: - Attachment: screenshot-xerces-ci-tests-trunk.png I've re-run the tests on our jenkins CI nodes. This repeated the previous tests described above, and all builds and tests passed. This tested FreeBSD (40 configuration combinations), Linux (80), MacOSX (40); and for Windows this included Cygwin (16), MinGW64 (16) and MSVC (64); totalling 256 unique configuration/platform combinations. I'm afraid that due to a recent jenkins security advisory, the jenkins jobs are not currently accessible to the outside world, so I've attached a screenshot showing the job status. This demonstrates that the cmake support is robust and hasn't regressed when rebased onto the trunk. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don
[jira] [Updated] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2077: - Attachment: 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch Updated patch to match library versioning with the existing build systems. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, > screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xerces was linked with, i.e. transitive depende
[jira] [Updated] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2077: - Attachment: (was: 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch) > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xerces was linked with, i.e. transitive dependencies. > - Installs the HTML documentation > - Targets are provided for regenerating the documentation (docs and > apidocs) >
[jira] [Updated] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2077: - Attachment: 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch Update to fix library versioning on Windows and Unix to retain full backward compatibility. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, > screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xerces was linked with, i.e. t
[jira] [Commented] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16002880#comment-16002880 ] Roger Leigh commented on XERCESC-2077: -- That's fine, thanks. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xerces was linked with, i.e. transitive dependencies. > - Installs the HTML documentation > - Targets are provided for regenerating the documentation (docs and > apidocs) > - Documentation can be ed
[jira] [Created] (XERCESC-2099) Support Standard C++ mutex
Roger Leigh created XERCESC-2099: Summary: Support Standard C++ mutex Key: XERCESC-2099 URL: https://issues.apache.org/jira/browse/XERCESC-2099 Project: Xerces-C++ Issue Type: Bug Components: Utilities Affects Versions: 3.2.0 Environment: Any supported platform Reporter: Roger Leigh Attachments: 0001-StdMutexMgr-Add-C-11-mutex-manager.patch Xerces-C currently supports POSIX and Win32 threading models with dedicated mutex manager classes. C++ standards since C\+\+11 support native mutexes which will work on any supported platform. The attached patch adds a {{StdMutexMgr}} class and the necessary Autoconf and CMake logic to check if C\+\+ mutexes are available. If not, it will fall back to the existing managers. On all but the most current compilers, it will continue to use POSIX/Win32 managers. On the most recent compilers, which default to C\+\+14, the standard mutexes will be used. On older compilers, the user must explicitly enable by setting {{CXXFLAGS=-std=c++11}} or later. See - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241340724] - [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.88] for build and test results. You'll see that GCC on Linux is using POSIX mutex, while clang on MacOS X is using standard mutex. On Windows, Cygwin uses POSIX mutex while MinGW and MSVC uses standard mutex. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2099) Support Standard C++ mutex
[ https://issues.apache.org/jira/browse/XERCESC-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16045071#comment-16045071 ] Roger Leigh commented on XERCESC-2099: -- Part of the motivation for this work is investigation into occasional random {{ThreadTest}} failures on FreeBSD which I've been noticing for some time, but haven't yet pinned down a cause. > Support Standard C++ mutex > -- > > Key: XERCESC-2099 > URL: https://issues.apache.org/jira/browse/XERCESC-2099 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0 > Environment: Any supported platform >Reporter: Roger Leigh > Labels: c++11, mutex > Attachments: 0001-StdMutexMgr-Add-C-11-mutex-manager.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > Xerces-C currently supports POSIX and Win32 threading models with dedicated > mutex manager classes. C++ standards since C\+\+11 support native mutexes > which will work on any supported platform. > The attached patch adds a {{StdMutexMgr}} class and the necessary Autoconf > and CMake logic to check if C\+\+ mutexes are available. If not, it will > fall back to the existing managers. > On all but the most current compilers, it will continue to use POSIX/Win32 > managers. On the most recent compilers, which default to C\+\+14, the > standard mutexes will be used. On older compilers, the user must explicitly > enable by setting {{CXXFLAGS=-std=c++11}} or later. > See > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241340724] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.88] > for build and test results. You'll see that GCC on Linux is using POSIX > mutex, while clang on MacOS X is using standard mutex. On Windows, Cygwin > uses POSIX mutex while MinGW and MSVC uses standard mutex. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2102) Documentation is not generatable on modern systems
[ https://issues.apache.org/jira/browse/XERCESC-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16057108#comment-16057108 ] Roger Leigh commented on XERCESC-2102: -- I can certainly run Java 1.6 in an old virtual machine if need be. Regarding wikis, how about conversion to markdown? It's supported by several wikis, but it also has the nice properly of being supported by GitHub, GitLab and others, so you can directly browse the documentation in the repo and have it nicely rendered. It would keep the maintenance burden low, and it's pretty accessible for anyone who wanted to work on any docs changes. > Documentation is not generatable on modern systems > -- > > Key: XERCESC-2102 > URL: https://issues.apache.org/jira/browse/XERCESC-2102 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation > Reporter: Roger Leigh > > The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}. > Unfortunately this tool appears to no longer be developed and it no longer > works with contemporary JREs due to relying upon > {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present. It's > achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming > increasingly difficult to make work. > Was there ever a migration path from slidebook to any other format which is > currently supported? > Would there be any interest in moving to a contemporary documentation format, > and if so are there any preferred formats? At work we use Sphinx. I'd be > happy to spend a few hours converting it to this or some other format which > is currently supported. > Regards, > Roger > {noformat} > % make createdocs > [StyleBook] Overriding > targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".") > [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml" > [BasicEngine] Initializing > [Loader] Parsing Project file > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl" > [XalanProcessor] Applying XSL sheet > "sbk:/style/stylesheets/directory2project.xsl" > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (1) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (2) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (3) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (4) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (5) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (6) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (7) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (8) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (9) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (10) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (11) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (12) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (13
[jira] [Updated] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2077: - Description: h4. Introduction The attached patch implements a CMake build for Xerces-C++. I have spent significant effort performing a "comprehensive" conversion of the existing GNU autotools and MSVC project file logic to a unified CMake build which supports all platforms with a single set of build files, as well as testing it exhaustively (see below). The existing GNU autotools build and MSVC project builds will continue to function and are unaffected by this addition. h5. References - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 h4. Background CMake is a meta-build system which generates the build files for a specified build system, such as make, Visual Studio msbuild, nmake, ninja or a number of other build tools and IDEs. This allows Xerces-C++ to be built on any supported platform with the native tools for that platform. The reason why I originally needed this was due to the large maintenance burden of patching the provided Visual Studio project files, both for fixing bugs in those files and in being able to support versions of Visual Studio which aren't yet supported by the provided project files or for unsupported configurations e.g. Clang/C2, other platforms etc. The lack of an install target also meant that to integrate this with a larger build required manually copying bits out of the build tree. The cost of debugging and patching the existing project files for use in our CI builds was getting too great--maintaining and using this CMake build out of tree will be cheaper and more robust. However, given that other people have also requested such support in the past, I thought it might benefit others to have this merged upstream so that it would be available to the benefit of all. I have done a direct conversion of every autoconf option and feature test. Where there wasn't a direct CMake equivalent, I've written each feature test to exactly match the autoconf behaviour. The automake Makefile.am logic is directly represented in the corresponding CMakeLists.txt files. Broadly: ||Autotools||CMake|| |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| |{{m4/*}}|{{cmake/*}}| |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| |_autoheader_|config.h.cmake.in| |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, {{samples/expected/\*}} (individual log files)| And there's a section added to the documentation giving an overview of how to use it, in the same style as the autotools section. h5. Enhancements over the existing build systems - Universal build for any platform and build system supported by CMake - Full support for feature and library detection on Windows, including discovery of ICU libraries; it's no longer static, using (long broken) ICU configurations in the project files - An install target now exists on Windows, so the various pieces don't need manually copying out of the build tree - Parallel build speed improvements when using ninja to replace make or msbuild; the speedup with the latter is significant - Export of CMake configuration in addition to pkg-config, to make Xerces-C++ integrate with downstream projects using Xerces-C++ and cmake; this includes all dependency information of the libraries Xerces was linked with, i.e. transitive dependencies. - Installs the HTML documentation - Targets are provided for regenerating the documentation (docs and apidocs) - Documentation can be edited and rebuilt from within Visual Studio - Unit tests can be run on all supported platforms - Unit tests can be run in parallel - Unit tests verify individual test output on all platforms - Unit tests can be run from within Visual Studio - All the Visual Studio projects are grouped into categories (Documentation, Library, Samples, Tests), making it neater and easier to navigate than with the existing solution files h5. Known differences: - The library naming differences have been resolved. On Unix platforms the libtool -release conventions are followed. On Windows with Visual Studio the project file conventions are followed. h4. Maintenance The logic in all files directly matches the corresponding autotools files to the maximum extent possible. For most updates to the autotools logic, the corresponding cmake change should be trivial and obvious, for example adding or removing source files from src/Makefile.am o
[jira] [Commented] (XERCESC-2075) Small corrections for Cygwin and MacOS X build instructions
[ https://issues.apache.org/jira/browse/XERCESC-2075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036106#comment-16036106 ] Roger Leigh commented on XERCESC-2075: -- Would there be any objection to committing these small fixes on the trunk and/or 3.1? > Small corrections for Cygwin and MacOS X build instructions > --- > > Key: XERCESC-2075 > URL: https://issues.apache.org/jira/browse/XERCESC-2075 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation >Affects Versions: 3.1.4 > Reporter: Roger Leigh >Priority: Minor > Attachments: > 0001-doc-build-Some-features-don-t-work-with-Cygwin.patch, > 0002-doc-build-Recommend-DYLD_FALLBACK_LIBRARY_PATH-rathe.patch > > > Small corrections and improvements for the build instructions. See attached > patches. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2077) Add CMake build system
[ https://issues.apache.org/jira/browse/XERCESC-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2077. -- Resolution: Fixed Fix Version/s: 3.2.0 The two patches were committed to the trunk in revision 1797546. > Add CMake build system > -- > > Key: XERCESC-2077 > URL: https://issues.apache.org/jira/browse/XERCESC-2077 > Project: Xerces-C++ > Issue Type: New Feature > Components: Build >Affects Versions: 3.1.4 > Environment: All >Reporter: Roger Leigh > Labels: build, cmake, patch > Fix For: 3.2.0 > > Attachments: 0001-cmake-Add-CMake-build-system.patch, > 0001-cmake-Add-CMake-build-system-trunk.patch, > 0002-cmake-Align-versioning-with-Autotools-and-Visual-Stu.patch, > screenshot-xerces-ci-tests-trunk.png > > > h4. Introduction > The attached patch implements a CMake build for Xerces-C++. > I have spent significant effort performing a "comprehensive" conversion of > the existing GNU autotools and MSVC project file logic to a unified CMake > build which supports all platforms with a single set of build files, as well > as testing it exhaustively (see below). The existing GNU autotools build and > MSVC project builds will continue to function and are unaffected by this > addition. > h5. References > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201302.mbox/browser > - http://mail-archives.apache.org/mod_mbox/xerces-c-dev/201506.mbox/browser > - https://github.com/rleigh-codelibre/xerces-c/tree/cmake-3.1 > h4. Background > CMake is a meta-build system which generates the build files for a specified > build system, such as make, Visual Studio msbuild, nmake, ninja or a number > of other build tools and IDEs. This allows Xerces-C++ to be built on any > supported platform with the native tools for that platform. > The reason why I originally needed this was due to the large maintenance > burden of patching the provided Visual Studio project files, both for fixing > bugs in those files and in being able to support versions of Visual Studio > which aren't yet supported by the provided project files or for unsupported > configurations e.g. Clang/C2, other platforms etc. The lack of an install > target also meant that to integrate this with a larger build required > manually copying bits out of the build tree. The cost of debugging and > patching the existing project files for use in our CI builds was getting too > great--maintaining and using this CMake build out of tree will be cheaper and > more robust. However, given that other people have also requested such > support in the past, I thought it might benefit others to have this merged > upstream so that it would be available to the benefit of all. > I have done a direct conversion of every autoconf option and feature test. > Where there wasn't a direct CMake equivalent, I've written each feature test > to exactly match the autoconf behaviour. The automake Makefile.am logic is > directly represented in the corresponding CMakeLists.txt files. Broadly: > ||Autotools||CMake|| > |{{configure.ac}}, {{Makefile.am}}|{{CMakeLists.txt}}| > |{{*/Makefile.am}}|{{*/CMakeLists.txt}}| > |{{m4/*}}|{{cmake/*}}| > |{{src/xercesc/util/Xerces_autoconf_config.hpp.in}}|{{src/xercesc/util/Xerces_autoconf_config.hpp.cmake.in}}| > |_autoheader_|config.h.cmake.in| > |{{tools/createdocs.sh}}|{{CMakeLists.txt}} (custom target)| > |{{scripts/sanityTest.pl}}|{{cmake/XercesTest.cmake}} (direct support)| > |{{scripts/sanityTest_ExpectedResult.log}}|{{test/expected/\*}}, > {{samples/expected/\*}} (individual log files)| > And there's a section added to the documentation giving an overview of how to > use it, in the same style as the autotools section. > h5. Enhancements over the existing build systems > - Universal build for any platform and build system supported by CMake > - Full support for feature and library detection on Windows, including > discovery of ICU libraries; it's no longer static, using (long broken) > ICU configurations in the project files > - An install target now exists on Windows, so the various pieces don't > need manually copying out of the build tree > - Parallel build speed improvements when using ninja to replace make > or msbuild; the speedup with the latter is significant > - Export of CMake configuration in addition to pkg-config, to make > Xerces-C++ integrate with downstream projects using Xerces-C++ and > cmake; this includes all dependency information of the libraries > Xerces was linked with, i.e. transitive dependencie
[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2098: - Description: The project does not currently have any continuous integration in place. I've spent the last few days getting a working solution to consider. The attached patch files add support for two commonly used services, [Travis|https://travis-ci.org/] (Unix) and [AppVeyor|https://www.appveyor.com] (Windows). See this [GitHub branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last commit has a green tick mark, which is the CI status. This links through to the build results: - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] - [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] How to use this? Go to the Travis or AppVeyor websites and log in with GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable the service for your xerces-c git repo. Now any branch you push to your git repo will be automatically built in several configuration combinations for Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 2015). The exact combinations tested are viewable with the above build links, or in the attached patch files. The set of test combinations can be adjusted as desired. This could additionally be enabled for the Apache GitHub mirror or the Apache git repo itself, which would trigger builds for all subversion commits to do post-commit testing. Would there be any objection to committing these changes? was: The project does not currently have any continuous integration in place. I've spent the last few days getting a working solution to consider. The attached patch files add support for two commonly used services, [Travis|https://travis-ci.org/] (Unix) and [AppVeyor|www.appveyor.com] (Windows). See this [GitHub branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last commit has a green tick mark, which is the CI status. This links through to the build results: - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] - [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] How to use this? Go to the Travis or AppVeyor websites and log in with GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable the service for your xerces-c git repo. Now any branch you push to your git repo will be automatically built in several configuration combinations for Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 2015). The exact combinations tested are viewable with the above build links, or in the attached patch files. The set of test combinations can be adjusted as desired. This could additionally be enabled for the Apache GitHub mirror or the Apache git repo itself, which would trigger builds for all subversion commits to do post-commit testing. Would there be any objection to committing these changes? > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Attachments: 0001-samples-Makefile.am-Add-missing-continuation.patch, > 0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0003-ci-Add-travis-support-for-Linux.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - > [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you p
[jira] [Commented] (XERCESC-2048) Error during build on Windows/MinGW because of LDFLAGS=-no-undefined
[ https://issues.apache.org/jira/browse/XERCESC-2048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043033#comment-16043033 ] Roger Leigh commented on XERCESC-2048: -- The new CMake support on the trunk will allow building and testing with MinGW, e.g. https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76/job/4vo6enhkhday4a72 > Error during build on Windows/MinGW because of LDFLAGS=-no-undefined > - > > Key: XERCESC-2048 > URL: https://issues.apache.org/jira/browse/XERCESC-2048 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.2, 3.1.3 > Environment: Windows 8.1 with MinGW >Reporter: Philip Young >Priority: Blocker > > Followed the build instructions and used ./configure LDFLAGS=-no-undefined > config.log shows the following: > Target: mingw32 > Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 > --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld > --enable-lto --enable-libssp --disable-multilib > --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions > --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug > --enable-version-specific-runtime-libs > --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld > --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= > --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp > --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw > --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T > Thread model: win32 > gcc version 4.8.1 (GCC) > configure:3781: $? = 0 > configure:3770: g++ -V >&5 > g++.exe: error: unrecognized command line option '-V' > g++.exe: fatal error: no input files > compilation terminated. > configure:3781: $? = 1 > configure:3770: g++ -qversion >&5 > g++.exe: error: unrecognized command line option '-qversion' > g++.exe: fatal error: no input files > compilation terminated. > configure:3781: $? = 1 > configure:3801: checking whether the C++ compiler works > configure:3823: g++ -no-undefined conftest.cpp >&5 > g++.exe: error: unrecognized command line option '-no-undefined' > configure:3827: $? = 1 > configure:3865: result: no > configure: failed program was: > | /* confdefs.h */ -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2098: - Attachment: (was: 0001-samples-Makefile.am-Add-missing-continuation.patch) > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Attachments: > 0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0003-ci-Add-travis-support-for-Linux.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - > [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you push to your git > repo will be automatically built in several configuration combinations for > Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC > 2015). The exact combinations tested are viewable with the above build > links, or in the attached patch files. The set of test combinations can be > adjusted as desired. > This could additionally be enabled for the Apache GitHub mirror or the Apache > git repo itself, which would trigger builds for all subversion commits to do > post-commit testing. > Would there be any objection to committing these changes? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2098) Add support for external continuous integration services
Roger Leigh created XERCESC-2098: Summary: Add support for external continuous integration services Key: XERCESC-2098 URL: https://issues.apache.org/jira/browse/XERCESC-2098 Project: Xerces-C++ Issue Type: Test Components: Miscellaneous Affects Versions: 3.2.0 Environment: Unix/Linux Windows (MSVC, Cygwin, MinGW) Reporter: Roger Leigh Attachments: 0001-samples-Makefile.am-Add-missing-continuation.patch, 0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, 0003-ci-Add-travis-support-for-Linux.patch The project does not currently have any continuous integration in place. I've spent the last few days getting a working solution to consider. The attached patch files add support for two commonly used services, [Travis|https://travis-ci.org/] (Unix) and [AppVeyor|www.appveyor.com] (Windows). See this [GitHub branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last commit has a green tick mark, which is the CI status. This links through to the build results: - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] - [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] How to use this? Go to the Travis or AppVeyor websites and log in with GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable the service for your xerces-c git repo. Now any branch you push to your git repo will be automatically built in several configuration combinations for Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 2015). The exact combinations tested are viewable with the above build links, or in the attached patch files. The set of test combinations can be adjusted as desired. This could additionally be enabled for the Apache GitHub mirror or the Apache git repo itself, which would trigger builds for all subversion commits to do post-commit testing. Would there be any objection to committing these changes? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1785) Build and test on all supported platforms
[ https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043025#comment-16043025 ] Roger Leigh commented on XERCESC-1785: -- Please see https://issues.apache.org/jira/browse/XERCESC-2098 for an attempt to automatically test on a range of common platforms. Looking at the platform list on the linked wiki page, it's quite out of date. Do we have a current list of platforms we should be supporting? > Build and test on all supported platforms > - > > Key: XERCESC-1785 > URL: https://issues.apache.org/jira/browse/XERCESC-1785 > Project: Xerces-C++ > Issue Type: Task > Components: Build >Reporter: Boris Kolpackov >Priority: Blocker > Fix For: 3.2.0 > > > We need to make sure that building, testing and installation work on all > platforms that we have committed to support. See the following Wiki page for > the status: > http://wiki.apache.org/xerces/XercescBuildStatus -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1785) Build and test on all supported platforms
[ https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16043052#comment-16043052 ] Roger Leigh commented on XERCESC-1785: -- I can certainly look at adding MacOS X to the work linked above; it's available as a supported platform, and it would ensure that the cfurl and macosxunicodeconverter options are in the test matrix. It's currently 64-bit only; probably fine for commit testing; the matrix could be extended to 32-bits for releases if we wanted, but if we're happy with source-only releases it's probably easier to delegate that to distributions for the most part. AppVeyor does produce downloadable zips, so we could link to Windows builds if we wanted, or just let people build their own. > Build and test on all supported platforms > - > > Key: XERCESC-1785 > URL: https://issues.apache.org/jira/browse/XERCESC-1785 > Project: Xerces-C++ > Issue Type: Task > Components: Build >Reporter: Boris Kolpackov >Priority: Blocker > Fix For: 3.2.0 > > > We need to make sure that building, testing and installation work on all > platforms that we have committed to support. See the following Wiki page for > the status: > http://wiki.apache.org/xerces/XercescBuildStatus -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2078) iconv message loader won't build when using current automake
[ https://issues.apache.org/jira/browse/XERCESC-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2078. -- Resolution: Fixed Fix Version/s: 3.2.0 SVN revision 1797568. > iconv message loader won't build when using current automake > > > Key: XERCESC-2078 > URL: https://issues.apache.org/jira/browse/XERCESC-2078 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.4 > Reporter: Roger Leigh > Labels: autotools, build, iconv, patch > Fix For: 3.2.0 > > Attachments: > 0001-build-Correct-use-of-mkdir_p-with-current-automake.patch > > > The existing {{Makefile.in}} in {{src/xerces/util/MsgLoader/MsgCatalog` uses > `$(mkdir_p)}}. However, with current (and not so current) automake versions > this is set to {{$(MKDIR_P)}}, but this variable is unset, leading to a > failed build: > {{gmake[4]: ../../../../../src/.libs: Command not found}} > (from > [build|https://ci.openmicroscopy.org/view/Experimental/job/XERCESC-AUTOTOOLS-BSD/build_type=Release,config=4,generator=Unix%20Makefiles,label=perch,shared=OFF/14/console]) > The attached patch substitutes the missing variable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2078) iconv message loader won't build when using current automake
[ https://issues.apache.org/jira/browse/XERCESC-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16036107#comment-16036107 ] Roger Leigh commented on XERCESC-2078: -- Would there be any objection to committing this one liner to the trunk and/or 3.1? > iconv message loader won't build when using current automake > > > Key: XERCESC-2078 > URL: https://issues.apache.org/jira/browse/XERCESC-2078 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.4 > Reporter: Roger Leigh > Labels: autotools, build, iconv, patch > Attachments: > 0001-build-Correct-use-of-mkdir_p-with-current-automake.patch > > > The existing {{Makefile.in}} in {{src/xerces/util/MsgLoader/MsgCatalog` uses > `$(mkdir_p)}}. However, with current (and not so current) automake versions > this is set to {{$(MKDIR_P)}}, but this variable is unset, leading to a > failed build: > {{gmake[4]: ../../../../../src/.libs: Command not found}} > (from > [build|https://ci.openmicroscopy.org/view/Experimental/job/XERCESC-AUTOTOOLS-BSD/build_type=Release,config=4,generator=Unix%20Makefiles,label=perch,shared=OFF/14/console]) > The attached patch substitutes the missing variable. -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047667#comment-16047667 ] Roger Leigh commented on XERCESC-2100: -- I've opened the ticket here in case anyone wanted to have a look over them and approve the changes. If there are no concerns with them, would it be OK to commit these on the trunk? Thanks, Roger > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047971#comment-16047971 ] Roger Leigh commented on XERCESC-2100: -- The main thing I can see in favour of a non-virtual dtor is not having a vtable and saving one pointer per parent class. But that may be a premature optimisation to make, and I'd personally value correctness and stability over a tiny performance gain. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047918#comment-16047918 ] Roger Leigh commented on XERCESC-2100: -- Yes, the reinterpret_cast instances look dodgy due to the alignment requirements; at least they are all easily found with grep when in the C++ form of the cast for future fixing. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047953#comment-16047953 ] Roger Leigh commented on XERCESC-2100: -- For 0012, it's something which GCC/clang were warning about. But looking at the code, {{DOMParentNode}} is always created as a concrete instance as a class member and never deleted via a pointer, so it's likely unnecessary to make this change. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Comment Edited] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16047971#comment-16047971 ] Roger Leigh edited comment on XERCESC-2100 at 6/13/17 2:38 PM: --- The main thing I can see in favour of a non-virtual dtor is not having a vtable and saving one vtable-pointer per parent class. But that may be a premature optimisation to make, and I'd personally value correctness and stability over a tiny performance gain. was (Author: rleigh): The main thing I can see in favour of a non-virtual dtor is not having a vtable and saving one pointer per parent class. But that may be a premature optimisation to make, and I'd personally value correctness and stability over a tiny performance gain. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2073) autoconf uses incorrect size_t and ssize_t fallback types
[ https://issues.apache.org/jira/browse/XERCESC-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2073. -- Resolution: Fixed Fix Version/s: 3.2.0 Fixed in 1798795. > autoconf uses incorrect size_t and ssize_t fallback types > - > > Key: XERCESC-2073 > URL: https://issues.apache.org/jira/browse/XERCESC-2073 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.4 > Environment: Using autoconf build >Reporter: Roger Leigh >Priority: Minor > Fix For: 3.2.0 > > Attachments: autoconf-size-fallbacks.patch > > > size_t is unsigned, ssize_t is signed. However, the fallback types are > swapped making them incorrect for their purpose. The attached patch > rectifies this oversight. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2103) Remove Win32 projects on the trunk
Roger Leigh created XERCESC-2103: Summary: Remove Win32 projects on the trunk Key: XERCESC-2103 URL: https://issues.apache.org/jira/browse/XERCESC-2103 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.2.0 Reporter: Roger Leigh Attachments: 0001-projects-Remove-Win32-projects.patch.xz The attached patch removes all the Win32 project files from the {{projects}} directory on the trunk. - [branch|https://github.com/rleigh-codelibre/xerces-c/commits/remove-projects] - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/243056449] - [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.95] It also drops the Windows and Borland instructions from the documentation. CMake will generate project and solution files for all the removed platforms. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2098: - Attachment: 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Attachments: > 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - > [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you push to your git > repo will be automatically built in several configuration combinations for > Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC > 2015). The exact combinations tested are viewable with the above build > links, or in the attached patch files. The set of test combinations can be > adjusted as desired. > This could additionally be enabled for the Apache GitHub mirror or the Apache > git repo itself, which would trigger builds for all subversion commits to do > post-commit testing. > Would there be any objection to committing these changes? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2098: - Attachment: (was: 0003-ci-Add-travis-support-for-Linux.patch) > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Attachments: > 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - > [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you push to your git > repo will be automatically built in several configuration combinations for > Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC > 2015). The exact combinations tested are viewable with the above build > links, or in the attached patch files. The set of test combinations can be > adjusted as desired. > This could additionally be enabled for the Apache GitHub mirror or the Apache > git repo itself, which would trigger builds for all subversion commits to do > post-commit testing. > Would there be any objection to committing these changes? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2098: - Attachment: (was: 0002-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch) > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Attachments: > 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - > [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you push to your git > repo will be automatically built in several configuration combinations for > Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC > 2015). The exact combinations tested are viewable with the above build > links, or in the attached patch files. The set of test combinations can be > adjusted as desired. > This could additionally be enabled for the Apache GitHub mirror or the Apache > git repo itself, which would trigger builds for all subversion commits to do > post-commit testing. > Would there be any objection to committing these changes? -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2098: - Description: The project does not currently have any continuous integration in place. I've spent the last few days getting a working solution to consider. The attached patch files add support for two commonly used services, [Travis|https://travis-ci.org/] (Unix) and [AppVeyor|https://www.appveyor.com] (Windows). See this [GitHub branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last commit has a green tick mark, which is the CI status. This links through to the build results: - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241140155] - [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.87] How to use this? Go to the Travis or AppVeyor websites and log in with GitHub/BitBucket/GitLab credentials, or use you own public git repo. Enable the service for your xerces-c git repo. Now any branch you push to your git repo will be automatically built in several configuration combinations for Linux (Autotools, CMake), MacOS X (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 2015). The exact combinations tested are viewable with the above build links, or in the attached patch files. The set of test combinations can be adjusted as desired. The initial set of combinations exercise all configurable options, debug and release builds. This could additionally be enabled for the Apache GitHub mirror or the Apache git repo itself, which would trigger builds for all subversion commits to do post-commit testing. Would there be any objection to committing these changes? was: The project does not currently have any continuous integration in place. I've spent the last few days getting a working solution to consider. The attached patch files add support for two commonly used services, [Travis|https://travis-ci.org/] (Unix) and [AppVeyor|https://www.appveyor.com] (Windows). See this [GitHub branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last commit has a green tick mark, which is the CI status. This links through to the build results: - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/240825536?utm_source=github_status_medium=notification] - [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.76] How to use this? Go to the Travis or AppVeyor websites and log in with GitHub/BitBucket|GitLab credentials, or use you own public git repo. Enable the service for your xerces-c git repo. Now any branch you push to your git repo will be automatically built in several configuration combinations for Linux (Autotools, CMake) and Windows (CMake with Cygwin, MingGW64 and MSVC 2015). The exact combinations tested are viewable with the above build links, or in the attached patch files. The set of test combinations can be adjusted as desired. This could additionally be enabled for the Apache GitHub mirror or the Apache git repo itself, which would trigger builds for all subversion commits to do post-commit testing. Would there be any objection to committing these changes? > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Attachments: > 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241140155] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.87] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket/GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you push to your gi
[jira] [Commented] (XERCESC-1785) Build and test on all supported platforms
[ https://issues.apache.org/jira/browse/XERCESC-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16044380#comment-16044380 ] Roger Leigh commented on XERCESC-1785: -- In the other ticket, I've added MacOS X to the list of test builds. Solaris/OpenSolaris doesn't seem to be well supported by these facilities, so I can't easily add that at present. > Build and test on all supported platforms > - > > Key: XERCESC-1785 > URL: https://issues.apache.org/jira/browse/XERCESC-1785 > Project: Xerces-C++ > Issue Type: Task > Components: Build >Reporter: Boris Kolpackov >Priority: Blocker > Fix For: 3.2.0 > > > We need to make sure that building, testing and installation work on all > platforms that we have committed to support. See the following Wiki page for > the status: > http://wiki.apache.org/xerces/XercescBuildStatus -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2100: - Description: These patches have been sitting around for nearly a year, but I've rebased them onto the trunk and tested them again. They cover several classes of fix: - minor build improvements - minor tweaks to feature tests - enabling stricter compiler warnings, and then fixing those warnings - fixing mismatched delete/delete[] (bad) - adding missing virtual destructors (bad) - removing unused variables - removing unused variables conditionally when used conditionally - removing cast warnings with appropriate C++ const/static/reinterpret casts Most of the fixes are tiny one-liners to fix warnings. Builds: - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] - [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] was: These patches have been sitting around for nearly a year, but I've rebased them onto the trunk and tested them again. Builds: - https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965 > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2100) [patch] Small fixes for warnings and errors
Roger Leigh created XERCESC-2100: Summary: [patch] Small fixes for warnings and errors Key: XERCESC-2100 URL: https://issues.apache.org/jira/browse/XERCESC-2100 Project: Xerces-C++ Issue Type: Bug Affects Versions: 3.2.0 Reporter: Roger Leigh Attachments: 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, 0002-cmake-Debug-FindThreads.patch, 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, 0005-cmake-Enable-extra-compiler-warnings.patch, 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, 0017-xercesc-XMLUri-Remove-unused-variables.patch, 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, 0020-tests-DTest-Remove-unused-variables.patch, 0021-tests-MemoryMonitor-Remove-unused-variable.patch, 0022-tests-XSTSHarness-Remove-unused-variables.patch, 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, 0026-xercesc-QName-Add-mising-const_casts.patch, 0027-xercesc-XMLUri-Add-missing-const_cast.patch, 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch These patches have been sitting around for nearly a year, but I've rebased them onto the trunk and tested them again. Builds: - https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965 -- This message was sent by Atlassian JIRA (v6.3.15#6346) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0001-cmake-Check-for-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland >Priority: Minor > Attachments: char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch 0002-cmake-Check-for-char16_t.patch 0003-autoconf-Check-for-char16_t.patch Update patches; now works with cmake and autoconf on Unix and Windows. > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland >Priority: Minor > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, > char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Issue Comment Deleted] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Comment: was deleted (was: I've tried your patch on the trunk with my cmake support (patch attached). Unfortunately it's failing here: {noformat} [266/343] Building CXX object src\CMakeFiles\xerces-c.dir\xercesc\util\Transcoders\Win32\Win32TransService.cpp.obj FAILED: src/CMakeFiles/xerces-c.dir/xercesc/util/Transcoders/Win32/Win32TransService.cpp.obj C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe /nologo /TP -DHAVE_CONFIG_H -DXERCES_BUILDING_LIBRARY -DXERCES_DLL_NAME=\"xerces-c_3_1d.dll\0\" -Dxerces_c_EXPORTS -I. -IH:\xerces-c\src -Isrc /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /Fosrc\CMakeFiles\xerces-c.dir\xercesc\util\Transcoders\Win32\Win32TransService.cpp.obj /Fdsrc\CMakeFiles\xerces-c.dir\ /FS -c H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp H:\xerces-c\src\xercesc/util/TransService.hpp(559): warning C4251: 'xercesc_3_1::TranscodeToStr::fString': class 'xercesc_3_1::ArrayJanitor' needs to have dll-interface to be used by clients of class 'xercesc_3_1::TranscodeToStr' H:\xerces-c\src\xercesc/util/TransService.hpp(559): note: see declaration of 'xercesc_3_1::ArrayJanitor' H:\xerces-c\src\xercesc/util/TransService.hpp(641): warning C4251: 'xercesc_3_1::TranscodeFromStr::fString': class 'xercesc_3_1::ArrayJanitor' needs to have dll-interface to be used by clients of class 'xercesc_3_1::TranscodeFromStr' H:\xerces-c\src\xercesc/util/TransService.hpp(641): note: see declaration of 'xercesc_3_1::ArrayJanitor' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(271): error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 'XMLCh *' to 'wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(271): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(289): error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 'XMLCh *' to 'wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(289): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(514): error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 'XMLCh *' to 'wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(514): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(529): error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 'XMLCh *' to 'wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(529): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(333): warning C4996: 'GetVersionExA': was declared deprecated C:\Program Files (x86)\Windows Kits\8.1\include\um\sysinfoapi.h(433): note: see declaration of 'GetVersionExA' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(569): error C2664: 'int _wcsicmp(const wchar_t *,const wchar_t *)': cannot convert argument 1 from 'const XMLCh *const ' to 'const wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(569): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(577): error C2664: 'int _wcsnicmp(const wchar_t *,const wchar_t *,std::size_t)': cannot convert argument 1 from 'const XMLCh *const ' to 'const wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(577): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(606): error C2664: 'wchar_t *_wcsupr(wchar_t *)': cannot convert argument 1 from 'XMLCh *const ' to 'wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(606): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(611): error C2664: 'wchar_t *_wcslwr(wchar_t *)': cannot convert argument 1 from 'XMLCh *const ' to 'wchar_t *' H:\xerces-c\src\xercesc\util\Transcoders\Win32\Win32TransService.cpp(611): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast H:\xerces-c\s
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: (was: 0002-autoconf-Check-for-char16_t.patch) > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland >Priority: Minor > Attachments: char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049226#comment-16049226 ] Roger Leigh commented on XERCESC-2101: -- - [Unix build results|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/242814234] - [Windows build results|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.92] All builds have passed using a mixture of old and new compilers using the previous defaults and char16_t, respectively. Overall, this is a fairly trivial change to a typedef with the changes to the supporting build infrastructure to detect and enable it. It enables the use of {{u"Unicode string"}}, which offers a significant usability improvement for end users of the library API, as well as a potential minor performance improvement by removing the need to transcode from 8-bit strings. No need to transcode to wide strings for every element and attribute name, it's all handled at compile time by the compiler. > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland >Priority: Minor > Attachments: > 0001-Add-Windows-support-for-XERCES_XMLCH_T-char16_t.patch, > 0002-cmake-Check-for-char16_t.patch, 0003-autoconf-Check-for-char16_t.patch, > char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049702#comment-16049702 ] Roger Leigh commented on XERCESC-2100: -- I've committed these minus the virtual dtor patches (12 and 13). I've also removed the extra compiler warning for non-virtual-dtors. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2100. -- Resolution: Fixed Fix Version/s: 3.2.0 Committed all patches with the exceptions of 12 and 13. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Fix For: 3.2.0 > > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2098) Add support for external continuous integration services
[ https://issues.apache.org/jira/browse/XERCESC-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2098. -- Resolution: Fixed Fix Version/s: 3.2.0 SVN revisions 1798779 and 1798780. > Add support for external continuous integration services > > > Key: XERCESC-2098 > URL: https://issues.apache.org/jira/browse/XERCESC-2098 > Project: Xerces-C++ > Issue Type: Test > Components: Miscellaneous >Affects Versions: 3.2.0 > Environment: Unix/Linux > Windows (MSVC, Cygwin, MinGW) >Reporter: Roger Leigh > Labels: appveyor, continuous_integration, travis-ci > Fix For: 3.2.0 > > Attachments: > 0001-ci-Add-appveyor-support-for-Cygwin-MinGW64-and-MSVC1.patch, > 0002-ci-Add-travis-support-for-Linux-and-MacOS-X.patch > > > The project does not currently have any continuous integration in place. > I've spent the last few days getting a working solution to consider. The > attached patch files add support for two commonly used services, > [Travis|https://travis-ci.org/] (Unix) and > [AppVeyor|https://www.appveyor.com] (Windows). > See this [GitHub > branch|https://github.com/rleigh-codelibre/xerces-c/commits/ci]. The last > commit has a green tick mark, which is the CI status. This links through to > the build results: > - [Travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241140155] > - > [AppVeyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.87] > How to use this? Go to the Travis or AppVeyor websites and log in with > GitHub/BitBucket/GitLab credentials, or use you own public git repo. Enable > the service for your xerces-c git repo. Now any branch you push to your git > repo will be automatically built in several configuration combinations for > Linux (Autotools, CMake), MacOS X (Autotools, CMake) and Windows (CMake with > Cygwin, MingGW64 and MSVC 2015). The exact combinations tested are viewable > with the above build links, or in the attached patch files. The set of test > combinations can be adjusted as desired. The initial set of combinations > exercise all configurable options, debug and release builds. > This could additionally be enabled for the Apache GitHub mirror or the Apache > git repo itself, which would trigger builds for all subversion commits to do > post-commit testing. > Would there be any objection to committing these changes? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2102) Documentation is not generatable on moderns systems
Roger Leigh created XERCESC-2102: Summary: Documentation is not generatable on moderns systems Key: XERCESC-2102 URL: https://issues.apache.org/jira/browse/XERCESC-2102 Project: Xerces-C++ Issue Type: Bug Components: Documentation Reporter: Roger Leigh The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}. Unfortunately this tool appears to no longer be developed and it no longer works with contemporary JREs due to relying upon {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present. It's achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming increasingly difficult to make work. Was there ever a migration path from slidebook to any other format which is currently supported? Would there be any interest in moving to a contemporary documentation format, and if so are there any preferred formats? At work we use Sphinx. I'd be happy to spend a few hours converting it to this or some other format which is currently supported. Regards, Roger {noformat} % make createdocs [StyleBook] Overriding targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".") [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml" [BasicEngine] Initializing [Loader] Parsing Project file [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl" [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/directory2project.xsl" [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (1) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (2) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (3) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (4) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (5) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (6) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (7) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (8) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (9) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (10) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (11) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (12) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (13) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (14) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (15) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (16) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (17) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" [CachingParser] Serving cached document "sbk:/style/stylesheets/any2project.xsl" (18) [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2p
[jira] [Updated] (XERCESC-2102) Documentation is not generatable on modern systems
[ https://issues.apache.org/jira/browse/XERCESC-2102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2102: - Summary: Documentation is not generatable on modern systems (was: Documentation is not generatable on moderns systems) > Documentation is not generatable on modern systems > -- > > Key: XERCESC-2102 > URL: https://issues.apache.org/jira/browse/XERCESC-2102 > Project: Xerces-C++ > Issue Type: Bug > Components: Documentation > Reporter: Roger Leigh > > The "stylebook" documentation format relies upon {{stylebook-1.0-b2.jar}}. > Unfortunately this tool appears to no longer be developed and it no longer > works with contemporary JREs due to relying upon > {com.sun.image.codec.jpeg.JPEGCodec} which is no longer present. It's > achievable by trying to find a Java 1.6 or earlier JRE, but this is becoming > increasingly difficult to make work. > Was there ever a migration path from slidebook to any other format which is > currently supported? > Would there be any interest in moving to a contemporary documentation format, > and if so are there any preferred formats? At work we use Sphinx. I'd be > happy to spend a few hours converting it to this or some other format which > is currently supported. > Regards, > Roger > {noformat} > % make createdocs > [StyleBook] Overriding > targetDirectory="/home/rleigh/code/xerces-svn-trunk/doc/html" (Old=".") > [StyleBook] Project URL: "sbk:/sources/xerces-c_book.xml" > [BasicEngine] Initializing > [Loader] Parsing Project file > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/book2project.xsl" > [XalanProcessor] Applying XSL sheet > "sbk:/style/stylesheets/directory2project.xsl" > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (1) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (2) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (3) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (4) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (5) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (6) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (7) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (8) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (9) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (10) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (11) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (12) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (13) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/stylesheets/any2project.xsl" (14) > [XalanProcessor] Applying XSL sheet "sbk:/style/stylesheets/any2project.xsl" > [CachingParser] Serving cached document > "sbk:/style/s
[jira] [Commented] (XERCESC-2073) autoconf uses incorrect size_t and ssize_t fallback types
[ https://issues.apache.org/jira/browse/XERCESC-2073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049804#comment-16049804 ] Roger Leigh commented on XERCESC-2073: -- - [branch|https://github.com/rleigh-codelibre/xerces-c/commits/autoconf-size-fallbacks] - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/243028832] - [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.94] > autoconf uses incorrect size_t and ssize_t fallback types > - > > Key: XERCESC-2073 > URL: https://issues.apache.org/jira/browse/XERCESC-2073 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.4 > Environment: Using autoconf build >Reporter: Roger Leigh >Priority: Minor > Attachments: autoconf-size-fallbacks.patch > > > size_t is unsigned, ssize_t is signed. However, the fallback types are > swapped making them incorrect for their purpose. The attached patch > rectifies this oversight. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2101) Add support for XERCES_XMLCH_T = char16_t
[ https://issues.apache.org/jira/browse/XERCESC-2101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2101: - Attachment: 0001-cmake-Check-for-char16_t.patch 0002-autoconf-Check-for-char16_t.patch Add cmake and autoconf support for char16_t > Add support for XERCES_XMLCH_T = char16_t > - > > Key: XERCESC-2101 > URL: https://issues.apache.org/jira/browse/XERCESC-2101 > Project: Xerces-C++ > Issue Type: Improvement >Reporter: Vemund Handeland >Priority: Minor > Attachments: 0001-cmake-Check-for-char16_t.patch, > 0002-autoconf-Check-for-char16_t.patch, char16_t.diff > > > Attached diff contains the required changes for msvc. The diff is from my > local git repo created from the 3.1.4 release. > Added new macro XERCES_USE_CHAR16_T. > User can enable the support by define this macro both when building the > library and her own application. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2100) [patch] Small fixes for warnings and errors
[ https://issues.apache.org/jira/browse/XERCESC-2100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16048004#comment-16048004 ] Roger Leigh commented on XERCESC-2100: -- For me, mainly for robustness in the face of future changes or refactoring. Right now it's not needed, of course, but it could avoid introducing buggy behaviour down the line, so is primarily defensive. > [patch] Small fixes for warnings and errors > --- > > Key: XERCESC-2100 > URL: https://issues.apache.org/jira/browse/XERCESC-2100 > Project: Xerces-C++ > Issue Type: Bug >Affects Versions: 3.2.0 > Reporter: Roger Leigh > Labels: patch > Attachments: > 0001-build-Merge-MsgCatalog-Makefile.in-with-src-Makefile.patch, > 0002-cmake-Debug-FindThreads.patch, > 0003-cmake-Minimum-C-standard-is-C-98-but-also-try-later-.patch, > 0004-cmake-XercesIntTypes-Add-a-cstdint-functional-check.patch, > 0005-cmake-Enable-extra-compiler-warnings.patch, > 0006-samples-PSVIWriterHandlers.cpp-Use-delete-in-place-o.patch, > 0007-tests-EncodingTest.cpp-Use-correct-format-strings-to.patch, > 0008-tests-DTest.cpp-Use-correct-format-strings-to-match-.patch, > 0009-tests-ThreadTest.cpp-Handle-all-node-types-in-switch.patch, > 0010-tests-XSValueTest-Don-t-warn-about-integer-limit-pro.patch, > 0011-xercesc-Don-t-warn-about-private-constructors-with-G.patch, > 0012-xercesc-DOMParentNode-Add-missing-virtual-destructor.patch, > 0013-xercesc-NamespaceScope-Add-missing-virtual-destructo.patch, > 0014-xercesc-NamespaceScope-Correct-initialisation-order.patch, > 0015-samples-PSVIWriterHandlers-Remove-unused-variables.patch, > 0016-xercesc-DOMLSSerializerImpl-Remove-unused-variable.patch, > 0017-xercesc-XMLUri-Remove-unused-variables.patch, > 0018-xercesc-RangeToken-Conditionally-define-variable-if-.patch, > 0019-xercesc-DatatypeValidatorFactory-Remove-unused-varia.patch, > 0020-tests-DTest-Remove-unused-variables.patch, > 0021-tests-MemoryMonitor-Remove-unused-variable.patch, > 0022-tests-XSTSHarness-Remove-unused-variables.patch, > 0023-tests-XSValueTest-Conditionally-define-conditionally.patch, > 0024-xercesc-PlatformUtils-Include-sys-timeb.h-conditiona.patch, > 0025-xercesc-BinMemInputStream-Add-missing-const_cast.patch, > 0026-xercesc-QName-Add-mising-const_casts.patch, > 0027-xercesc-XMLUri-Add-missing-const_cast.patch, > 0028-xercesc-DOMLSSerializerImpl-Suppress-cast-alignment-.patch, > 0029-xercesc-EncodingValidator-Suppress-cast-alignment-wa.patch, > 0030-xercesc-XProtoType-Suppress-cast-alignment-warning.patch, > 0031-xercesc-DOMCasts-Suppress-cast-alignment-warnings.patch, > 0032-xercesc-XMLReader-Suppress-cast-alignment-warnings.patch, > 0033-xercesc-XSerializeEngine-Suppress-cast-alignment-war.patch, > 0034-xercesc-XML-Transcoder-Suppress-cast-alignment-warni.patch, > 0035-xercesc-CMStateSet-Suppress-cast-alignment-warnings.patch > > > These patches have been sitting around for nearly a year, but I've rebased > them onto the trunk and tested them again. They cover several classes of fix: > - minor build improvements > - minor tweaks to feature tests > - enabling stricter compiler warnings, and then fixing those warnings > - fixing mismatched delete/delete[] (bad) > - adding missing virtual destructors (bad) > - removing unused variables > - removing unused variables conditionally when used conditionally > - removing cast warnings with appropriate C++ const/static/reinterpret casts > Most of the fixes are tiny one-liners to fix warnings. > Builds: > - [travis|https://travis-ci.org/rleigh-codelibre/xerces-c/builds/241812965] > - > [appveyor|https://ci.appveyor.com/project/rleigh-codelibre/xerces-c/build/1.0.90] -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2121) xercesc-3.2.0 fails to configure with cmake, gnuiconv on Solaris.
[ https://issues.apache.org/jira/browse/XERCESC-2121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186371#comment-16186371 ] Roger Leigh commented on XERCESC-2121: -- Thanks for picking this up. I'm not sure how those typos ended up there; maybe a regex without a trailing {g}. > xercesc-3.2.0 fails to configure with cmake, gnuiconv on Solaris. > - > > Key: XERCESC-2121 > URL: https://issues.apache.org/jira/browse/XERCESC-2121 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Solaris, gnuiconv present and selected with > -Dtranscoder=gnuiconv >Reporter: Fj >Priority: Minor > Attachments: xercesc.patch > > > Looks like a simple typo: variable names should use underscores instead of > slashes. This patch fixes it: > {code} > --- xerces-c-3.2.0/cmake/XercesTranscoderSelection.cmake.orig 2017-09-22 > 17:15:15.892155444 +0300 > +++ xerces-c-3.2.0/cmake/XercesTranscoderSelection.cmake2017-09-22 > 17:18:21.663148228 +0300 > @@ -59,7 +59,7 @@ > set(gnuiconv_available 0) > if(HAVE_ICONV_H AND HAVE_WCHAR_H AND HAVE_STRING_H AND HAVE_STDLIB_H AND > HAVE_STDIO_H AND HAVE_CTYPE_H AND HAVE_LOCALE_H AND HAVE_ERRNO_H) > - if (HAVE_ENDIAN_H OR HAVE_MACHINE/ENDIAN_H OR HAVE_ARPA/NAMESER_COMPAT_H) > + if (HAVE_ENDIAN_H OR HAVE_MACHINE_ENDIAN_H OR HAVE_ARPA_NAMESER_COMPAT_H) > if(HAVE_ICONV_OPEN AND HAVE_ICONV_CLOSE AND HAVE_ICONV) >set(gnuiconv_available 1) >list(APPEND transcoders gnuiconv) > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2114) Link failure with Xalan-C
[ https://issues.apache.org/jira/browse/XERCESC-2114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16186278#comment-16186278 ] Roger Leigh commented on XERCESC-2114: -- [~mat] That's very interesting. If you have a chance to retry building 3.1 with VS vs 3.2 with CMake I'd be very interested what the compiler flag discrepancy might be, so we can add back the missing flag (or remove the extra flag etc.). > Link failure with Xalan-C > - > > Key: XERCESC-2114 > URL: https://issues.apache.org/jira/browse/XERCESC-2114 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: VS2013 on Windows Server 2012R2 >Reporter: Roger Leigh > > Testing latest rc1 with xalan and VS2013: > [Build > log|https://ci.openmicroscopy.org/view/Files/job/OME-FILES-CPP-DEV-merge-win-superbuild/VSARCH=x64,VSCONFIG=Release,VSVERSION=12,label=maxquant-ome/714/console] > Using [this > patch|https://raw.githubusercontent.com/ome/ome-cmake-superbuild/master/packages/xalan/patches/win-vc12.diff] > to build Xalan with VS2013 (it's just the upgraded project files). > {noformat} > 12:29:32(Link target) -> > 12:29:32 XalanDiagnosticMemoryManager.obj : error LNK2001: > unresolved external symbol "__declspec(dllimport) unsigned __int64 const > `public: static unsigned __int64 __cdecl > xercesc_3_2::XMLPlatformUtils::alignPointerForNewBlockAllocation(unsigned > __int64)'::`2'::alignment" > (__imp_?alignment@?1??alignPointerForNewBlockAllocation@XMLPlatformUtils@xercesc_3_2@@SA_K_K@Z@4_KB) > > [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj] > 12:29:32 ..\..\..\..\Build\Win64\VC12\Release\Xalan-C_1_11.dll : > fatal error LNK1120: 1 unresolved externals > [D:\build\OME-FILES-CPP-DEV-merge-win-superbuild\2a8f6256\build\xalan-source\c\Projects\Win32\VC12\AllInOne\AllInOne.vcxproj] > {noformat} > Is there any incompatible change expected here? Could potentially be missing > symbol exports or anything of that nature? -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2125) CMake variable for nothreads does not match generated config define
[ https://issues.apache.org/jira/browse/XERCESC-2125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16312925#comment-16312925 ] Roger Leigh commented on XERCESC-2125: -- Interestingly, after fixing the variable name this shows up a possible flaw in the autoconf/make build. If you disable threads, it's still linking everything with pthreads, including the thread tests, so it's not really "nothread" at all! This includes all the thread tests. > CMake variable for nothreads does not match generated config define > --- > > Key: XERCESC-2125 > URL: https://issues.apache.org/jira/browse/XERCESC-2125 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.2.0 > Environment: Windows 8.1 64 bit, Visual Studio 2015, CMake 3.9.1 >Reporter: Sam Vanheer > > When the mutex manager is set to nothreads, the generated config will not > enable the XERCES_USE_MUTEXMGR_NOTHREAD definition. > This is because the configure_file function takes CMake variable names to use > for #cmakedefine, but the name for that configuration is > XERCES_USE_MUTEXMGR_NOTHREADS, defined in cmake/XercesMutexMgrSelection.cmake. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Resolved] (XERCESC-2119) warning C4251: 'xercesc_3_2::TranscodeToStr::fString': class 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used by clients of class 'xercesc_3
[ https://issues.apache.org/jira/browse/XERCESC-2119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh resolved XERCESC-2119. -- Resolution: Fixed Assignee: Roger Leigh Fix Version/s: 3.2.1 Fix committed in SVN commit 1820126. I've tested with VS2017 x64 on Windows 10 with and without the change, as well as with GCC 7.2 on Linux. Tests pass in all cases on both. > warning C4251: 'xercesc_3_2::TranscodeToStr::fString': class > 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used > by clients of class 'xercesc_3_2::TranscodeToStr' > -- > > Key: XERCESC-2119 > URL: https://issues.apache.org/jira/browse/XERCESC-2119 > Project: Xerces-C++ > Issue Type: Bug > Components: Utilities >Affects Versions: 3.2.0 > Environment: windows >Reporter: Mathieu Champlon >Assignee: Roger Leigh > Fix For: 3.2.1 > > Attachments: dll_interface.patch > > > Upgrading from xerces 3.1.2 to 3.2.0 on windows introduces a few of > {noformat} > (...)\include\xercesc/util/TransService.hpp(559): error C2220: warning > treated as error - no 'object' file generated > (...)\include\xercesc/util/TransService.hpp(559): warning C4251: > 'xercesc_3_2::TranscodeToStr::fString': class > 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used > by clients of class 'xercesc_3_2::TranscodeToStr' > (...)\include\xercesc/util/TransService.hpp(559): note: see declaration of > 'xercesc_3_2::ArrayJanitor' > (...)\include\xercesc/util/TransService.hpp(641): warning C4251: > 'xercesc_3_2::TranscodeFromStr::fString': class > 'xercesc_3_2::ArrayJanitor' needs to have dll-interface to be used by > clients of class 'xercesc_3_2::TranscodeFromStr' > (...)\include\xercesc/util/TransService.hpp(641): note: see declaration of > 'xercesc_3_2::ArrayJanitor' > {noformat} > As pragma deactivating C4251 is frown upon on the project I work, I ended up > exporting the types, see attached patch. > Note that this was also mentioned in XERCESC-1974. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2130) UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 3.2.0 (e.g. emoticons)
[ https://issues.apache.org/jira/browse/XERCESC-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334086#comment-16334086 ] Roger Leigh commented on XERCESC-2130: -- I'm not a legal expert, and I don't know where the Apache organisation draws the line between trivial and non-trivial contributions which require a CLA, but I suspect this counts as non-trivial. I think you would need to fill out an [individual CLA]([https://www.apache.org/licenses/#clas)] to allow this to be included. However, others might wish to correct me if I'm wrong. > UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces > 3.2.0 (e.g. emoticons) > > > Key: XERCESC-2130 > URL: https://issues.apache.org/jira/browse/XERCESC-2130 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.0 >Reporter: Andreas Krantz >Priority: Critical > Attachments: fix.patch, patch_.cpp, reproduce.cpp > > > Solution for XERCESC-1854 introduced method > {{DOMLSSerializerImpl::ensureValidString}} > which has an error in validation. > The method validates XMLCh which represent UTF16. > [Valid Characters|https://www.w3.org/TR/REC-xml/#NT-Char] #x9 | #xA | #xD | > [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] > are the valid UTF32 characters. > The UTF16 surrogate range from xD800 - xDFFF is used to represent > [#x1-#x10] and should not be handled as nvalid. > *The reader threads this correctly and does not complain, which leads to an > asmetric behavior* > Reading DOM => OK > Save back DOM => Exception > I tried to attach an example to show the behavior. > The used methods > {{bool XMLChar1_1::isXMLChar(const XMLCh toCheck, const XMLCh toCheck2)}} > already have a second optional parameter to check surrogate values. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2130) UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 3.2.0 (e.g. emoticons)
[ https://issues.apache.org/jira/browse/XERCESC-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16334103#comment-16334103 ] Roger Leigh commented on XERCESC-2130: -- Regarding signing, I did my work on my employer's time for at least some of it, so I had to get them to also sign a corporate CLA. It wasn't a problem, but it was a massive pain due to it taking about six months to be approved. May be easier for smaller organisations with less tortuous bureaucracy! > UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces > 3.2.0 (e.g. emoticons) > > > Key: XERCESC-2130 > URL: https://issues.apache.org/jira/browse/XERCESC-2130 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.0 >Reporter: Andreas Krantz >Priority: Critical > Attachments: fix.patch, patch_.cpp, reproduce.cpp > > > Solution for XERCESC-1854 introduced method > {{DOMLSSerializerImpl::ensureValidString}} > which has an error in validation. > The method validates XMLCh which represent UTF16. > [Valid Characters|https://www.w3.org/TR/REC-xml/#NT-Char] #x9 | #xA | #xD | > [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] > are the valid UTF32 characters. > The UTF16 surrogate range from xD800 - xDFFF is used to represent > [#x1-#x10] and should not be handled as nvalid. > *The reader threads this correctly and does not complain, which leads to an > asmetric behavior* > Reading DOM => OK > Save back DOM => Exception > I tried to attach an example to show the behavior. > The used methods > {{bool XMLChar1_1::isXMLChar(const XMLCh toCheck, const XMLCh toCheck2)}} > already have a second optional parameter to check surrogate values. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2130) UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces 3.2.0 (e.g. emoticons)
[ https://issues.apache.org/jira/browse/XERCESC-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16323829#comment-16323829 ] Roger Leigh commented on XERCESC-2130: -- Ouch, emoticons were a bit of a low blow! I'm not sure what the threshold is for contributions to require it, but have you already submitted the Apache CLA? Thanks, Roger > UTF16 Surrgate values 0xD800-0xDFFF can not longer be written with xerces > 3.2.0 (e.g. emoticons) > > > Key: XERCESC-2130 > URL: https://issues.apache.org/jira/browse/XERCESC-2130 > Project: Xerces-C++ > Issue Type: Bug > Components: DOM >Affects Versions: 3.2.0 >Reporter: Andreas Krantz >Priority: Critical > Attachments: fix.patch, patch_.cpp, reproduce.cpp > > > Solution for XERCESC-1854 introduced method > {{DOMLSSerializerImpl::ensureValidString}} > which has an error in validation. > The method validates XMLCh which represent UTF16. > [Valid Characters|https://www.w3.org/TR/REC-xml/#NT-Char] #x9 | #xA | #xD | > [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x1-#x10] > are the valid UTF32 characters. > The UTF16 surrogate range from xD800 - xDFFF is used to represent > [#x1-#x10] and should not be handled as nvalid. > *The reader threads this correctly and does not complain, which leads to an > asmetric behavior* > Reading DOM => OK > Save back DOM => Exception > I tried to attach an example to show the behavior. > The used methods > {{bool XMLChar1_1::isXMLChar(const XMLCh toCheck, const XMLCh toCheck2)}} > already have a second optional parameter to check surrogate values. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Created] (XERCESC-2134) CMake build missing support for Win32MsgLoader
Roger Leigh created XERCESC-2134: Summary: CMake build missing support for Win32MsgLoader Key: XERCESC-2134 URL: https://issues.apache.org/jira/browse/XERCESC-2134 Project: Xerces-C++ Issue Type: Improvement Components: Build Affects Versions: 3.2.0 Reporter: Roger Leigh Assignee: Roger Leigh The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was copied from, so all Windows builds are currently defaulting to the InMemoryMsgLoader. This is an unintentional omission which is simple to correct. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2134) Remove non-functional Win32MsgLoader code
[ https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2134: - Summary: Remove non-functional Win32MsgLoader code (was: CMake build missing support for Win32MsgLoader) > Remove non-functional Win32MsgLoader code > - > > Key: XERCESC-2134 > URL: https://issues.apache.org/jira/browse/XERCESC-2134 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.2.0 > Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > > The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was > copied from, so all Windows builds are currently defaulting to the > InMemoryMsgLoader. This is an unintentional omission which is simple to > correct. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2134) CMake build missing support for Win32MsgLoader
[ https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345346#comment-16345346 ] Roger Leigh commented on XERCESC-2134: -- Looking more closely, the Windows builds in 3.1 were already using the InMemory message loader, so there weren't any users of this code. Looking more closely at it: static const char* const privDLLName = "IXUTIL"; fModHandle = ::GetModuleHandleA(privDLLName); it looks like this code wouldn't be functional in any case (there's no IXUTIL module, and it's not clear where the resources it would load come from–there's no remaining logic to generate them). Would anyone object to this old, unused and non-functional code being removed from the source repository? > CMake build missing support for Win32MsgLoader > -- > > Key: XERCESC-2134 > URL: https://issues.apache.org/jira/browse/XERCESC-2134 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.2.0 >Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > > The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was > copied from, so all Windows builds are currently defaulting to the > InMemoryMsgLoader. This is an unintentional omission which is simple to > correct. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Updated] (XERCESC-2134) Remove non-functional Win32MsgLoader code
[ https://issues.apache.org/jira/browse/XERCESC-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roger Leigh updated XERCESC-2134: - Attachment: 0001-Remove-unused-and-broken-Win32MsgLoader.patch > Remove non-functional Win32MsgLoader code > - > > Key: XERCESC-2134 > URL: https://issues.apache.org/jira/browse/XERCESC-2134 > Project: Xerces-C++ > Issue Type: Improvement > Components: Build >Affects Versions: 3.2.0 > Reporter: Roger Leigh >Assignee: Roger Leigh >Priority: Major > Attachments: 0001-Remove-unused-and-broken-Win32MsgLoader.patch > > > The Win32MsgLoader wasn't present in the Makefile.am the CMakeLists.txt was > copied from, so all Windows builds are currently defaulting to the > InMemoryMsgLoader. This is an unintentional omission which is simple to > correct. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-1942) Xerces64 bit build with ICU3.6 64 bit does not Support encodings
[ https://issues.apache.org/jira/browse/XERCESC-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16345792#comment-16345792 ] Roger Leigh commented on XERCESC-1942: -- [~dineshkumar] Is this still an issue with current Xerces 3.2.0 and a current ICU release? > Xerces64 bit build with ICU3.6 64 bit does not Support encodings > > > Key: XERCESC-1942 > URL: https://issues.apache.org/jira/browse/XERCESC-1942 > Project: Xerces-C++ > Issue Type: Bug > Components: Samples/Tests >Affects Versions: 3.1.1 >Reporter: dinesh kumar >Priority: Major > > I built 64 bit Xerces 3.1 with ICU 3.6 with VIsual Studio 2008 on windows > 2008. I am able to compile the code completely after changing the Project > settings of ICU and used Win64 preprocessor in C/C++ preprocessor settings. > Attempt to test the build if xerces supports Big5 encoding and other encoding > seems to fail. > I tested with SAX2print.exe sample to convert to a particular Big5 encoding > and it says , unable to create converter for Big5. > Tested 64 bit Xerces 3.1 build with ICu 4.0 with visual studio 2008 also > fails with the test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org