Re: Integrating CMake support for xerces
Vitaly Prapirny wrote on 22/06/2017 10:53:
Roger Leigh wrote on 21/06/2017 17:40:
That line (PlatformUtils.cpp:27) is
#if HAVE_CONFIG_H
#include
#endif
so it either can't cope with "#if xxx" (which is used in many
places), or the error is in the generated "config.h". I'm afraid
you'll need to identify the cause of the error here. Can you include
config.h in a single test file like this:
#if HAVE_CONFIG_H
#include
#endif
int main()
{}
with or without the #if/endif? If you can pinpoint where the problem
is, we can look at further fixes.
Compilation of that single test file failed with just the same error
"Expression syntax" when HAVE_CONFIG_H defined without value
(-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or
defined with value (-DHAVE_CONFIG_H=1)
Roger,
After you fix that, I've got another error:
[ 80%] Linking CXX shared library xerces-c.dll
Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland
Error E2194: Could not find file '@CMakeFiles\xerces-c.dir\objects1.rsp'
Good luck!
Vitaly
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Integrating CMake support for xerces
Roger Leigh wrote on 21/06/2017 17:40:
That line (PlatformUtils.cpp:27) is
#if HAVE_CONFIG_H
#include
#endif
so it either can't cope with "#if xxx" (which is used in many places),
or the error is in the generated "config.h". I'm afraid you'll need
to identify the cause of the error here. Can you include config.h in
a single test file like this:
#if HAVE_CONFIG_H
#include
#endif
int main()
{}
with or without the #if/endif? If you can pinpoint where the problem
is, we can look at further fixes.
Compilation of that single test file failed with just the same error
"Expression syntax" when HAVE_CONFIG_H defined without value
(-DHAVE_CONFIG_H). It succeeded when HAVE_CONFIG_H undefined or defined
with value (-DHAVE_CONFIG_H=1)
Good luck!
Vitaly
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Integrating CMake support for xerces
Roger Leigh wrote on 21/06/2017 13:58: Sorry, too hasty. Please try this revised patch which actually works. CMake worked without error, but compilation failed just the same way as in my previous message. Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Integrating CMake support for xerces
Roger Leigh wrote on 21/06/2017 13:17: Thanks. This was a problem with the int type check fallbacks. Please see the attached patch or this github branch: https://github.com/rleigh-codelibre/xerces-c/tree/cmake-int-fallback This was a search-replace error when porting m4/xerces_int_types, and all the systems I've tested on all had stdint.h or cstdint, so I didn't notice this wasn't working. I've switched all the types to be unambiguously signed, and added SIGNED_ to all the variable names where missing. If you could give that a go, I'd be very interested if this works for you, or if you hit any other problems after this point. CMake worked without error in that branch, but compilation failed (make log attached). Good luck! Vitaly MAKE Version 5.2 Copyright (c) 1987, 2000 Borland MAKE Version 5.2 Copyright (c) 1987, 2000 Borland MAKE Version 5.2 Copyright (c) 1987, 2000 Borland Scanning dependencies of target xerces-c MAKE Version 5.2 Copyright (c) 1987, 2000 Borland [ 0%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/Base64.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\Base64.cpp: [ 0%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/BinFileInputStream.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinFileInputStream.cpp: [ 1%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/BinInputStream.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinInputStream.cpp: [ 1%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/BinMemInputStream.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BinMemInputStream.cpp: [ 1%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/BitSet.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\BitSet.cpp: [ 1%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/DefaultPanicHandler.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\DefaultPanicHandler.cpp: [ 2%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/EncodingValidator.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\EncodingValidator.cpp: [ 2%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/HeaderDummy.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\HeaderDummy.cpp: [ 2%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/HexBin.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\HexBin.cpp: [ 2%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/KVStringPair.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\KVStringPair.cpp: [ 3%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/Mutexes.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\Mutexes.cpp: [ 3%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/PanicHandler.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PanicHandler.cpp: [ 3%] Building CXX object src/CMakeFiles/xerces-c.dir/xercesc/util/PlatformUtils.cpp.obj Borland C++ 5.5.1 for Win32 Copyright (c) 1993, 2000 Borland E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PlatformUtils.cpp: Error E2188 E:\__\xerces\xerces-c-cmake-int-fallback\src\xercesc\util\PlatformUtils.cpp 27: Expression syntax *** 1 errors in Compile *** ** error 1 ** deleting src\CMakeFiles\xerces-c.dir\xercesc\util\PlatformUtils.cpp.obj ** error 1 ** deleting src\CMakeFiles\xerces-c.dir\all ** error 1 ** deleting all - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Integrating CMake support for xerces
Roger Leigh wrote on 21/06/2017 12:20: On 21/06/17 08:48, Vitaly Prapirny wrote: I've got an error while running cmake with "Borland Makefiles" generator and Borland C++ Builder 5 compiler. Is BCB5 still supported? It's not a combination I've personally tested, but I can't see any evidence that it shouldn't work. What are the errors you are seeing? Maybe it just needs a few minor tweaks to our cmake logic. I've attached log files to the https://issues.apache.org/jira/browse/XERCESC-2077 Good luck! Vitaly - 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
]
Vitaly Prapirny updated XERCESC-2077:
-
Attachment: cmake_bcb5_err.zip
CMake error with "Borland Makefiles" generator and Borland C++ Builder 5
compiler.
> 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 downstream projects using Xerces-C++ and
> cmake; this includes all dependency information of the libraries
> Xerces was lin
Re: Integrating CMake support for xerces
Roger Leigh wrote on 21/06/2017 09:54: On 21/06/17 02:42, Cantor, Scott wrote: Are the Xerces_autoconf_config.borland.hpp and Xerces_autoconf_config.msvc.hpp files "pre-cmake"? IIRC, I think those are the hardwired versions used in the old builds. I don't want to leave them on trunk if they're going to atrophy and I don't really imagine we'd be doing anything to ensure they worked if the solution files came from cmake now. Yes, these are only used by the old project files. CMake ignores them entirely, so they can certainly be removed. I've got an error while running cmake with "Borland Makefiles" generator and Borland C++ Builder 5 compiler. Is BCB5 still supported? Good luck! Vitaly - 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=16048001#comment-16048001 ] Vitaly Prapirny commented on XERCESC-2100: -- How adding virtual destructor to class, not used as base class, can improve correctness and stability? > [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-2086) Building Xalan & xerces on Oracle Linux 6.6 & Compiler solarisstudio12.3 C++ compiler for Linux
[
https://issues.apache.org/jira/browse/XERCESC-2086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15834657#comment-15834657
]
Vitaly Prapirny commented on XERCESC-2086:
--
Did you try to compile and run samples and tests instead of your application?
> Building Xalan & xerces on Oracle Linux 6.6 & Compiler solarisstudio12.3 C++
> compiler for Linux
>
>
> Key: XERCESC-2086
> URL: https://issues.apache.org/jira/browse/XERCESC-2086
> Project: Xerces-C++
> Issue Type: Task
> Components: Build
>Affects Versions: 2.7.0
> Environment: Platform:- Oracle Linux 6.6
> Compiler :- solarisstudio12.3 C++ compiler for Linux
>Reporter: Chirag Agrawal
>Priority: Blocker
> Labels: build
>
> Hi Team,
> I am facing issue while using Xalan & Xerces for my application.
> Below are my environment details i am using :-
> Platform:- Oracle Linux 6.6
> Compiler :- solarisstudio12.3 C++ compiler for Linux
> Below are the versions of Xalan & Xerces source code used to build the shared
> object downloaded from Apache site:-
> xerces-c-src_2_7_0.tar.gz
> Xalan-C_1_10_0-src.tar.gz
> Problem Description:-
> I had to build 32 bit shared object which can be used in my application. so i
> tried building xerces with the options for my platform as :-
> ./runConfigure -plinux -ccc -xCC
> i added -m32 falg in makefile and it got compiled and created a shared object.
> Then i tried to configure xalan with below command :-
> ./runConfigure -plinux -ccc -xCC
> I tried to compile it but it resulted me in lot of errors. i tried fixing
> them in order to change compiler and platform defines header files and some
> make files.
> Finally i was able to create 32 bit shared object for xalan.
> I then tried to use in my application but it was throwing coredump at
> function XalanMemMgrs::getDefaultXercesMemMgr().
> Below is the code sniplet for the issue :-
> XalanMemMgrs::getDefaultXercesMemMgr()
> {
> XALAN_USING_XERCES(XMLPlatformUtils)
> MemoryManagerType* ptr = XMLPlatformUtils::fgMemoryManager;
> assert (ptr != 0);
> return *ptr;
> (dbx:getDefaultXercesMemMgr) display XMLPlatformUtils
> dbx: "XMLPlatformUtils" is not defined in the scope
> `libxalan-c.so.110`XalanMemoryManagement.cpp`xalanc_1_10::XalanMemMgrs::getDefaultXercesMemMgr()`
> dbx: see `help scope' for details
> (dbx:getDefaultXercesMemMgr) n
> t@4079109952 (l@21431) stopped in
> xalanc_1_10::XalanMemMgrs::getDefaultXercesMemMgr at line 73 in file
> "XalanMemoryManagement.cpp"
>73 assert (ptr != 0);
> The value of ptr is showing as nil.
> Need your urgent help in order to understand the changes for my platform
> requirement and how to sort this memory related issue.
> Regards
> Chirag Agrawal
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Xerces-C 3.1.4 released
Thanks Scott! Good luck! Vitaly Cantor, Scott wrote: A patch release of the Xerces-C XML parser is now available and is propagating to the mirrors. It includes a small number of important bug fixes, including a fix for CVE-2016-4463. https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10510=12336069 Of special note, applications that don't make use of DTDs should strongly consider setting the XERCES_ DISABLE_DTD environment variable to "1" to insulate themselves from the likelihood of future vulnerabilities in that code. When I have a free moment I will make that a parser feature in the trunk since it requires an ABI change. -- Scott - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2065) Carriage return entities are not handled properly
[
https://issues.apache.org/jira/browse/XERCESC-2065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15229890#comment-15229890
]
Vitaly Prapirny commented on XERCESC-2065:
--
The CR entity was not removed but printed to the console accordingly. Please
redirect the output to a file and see result.
> Carriage return entities are not handled properly
> -
>
> Key: XERCESC-2065
> URL: https://issues.apache.org/jira/browse/XERCESC-2065
> Project: Xerces-C++
> Issue Type: Bug
> Components: DOM, Non-Validating Parser, SAX/SAX2
>Affects Versions: 3.1.3
>Reporter: Scott Cantor
>Priority: Critical
>
> Documents with CR entities don't seem to round trip properly in the parser if
> you parse them and then serialize them. It's possible the bug is in the
> serializer because signed documents don't end up with corrupt signatures, but
> that may be due to insufficient testing as of yet.
> A simple example:
> {code}
>
>
>textmore
>
> {code}
> Running that through DOMPrint or SAX2Print:
> {code}
>
> more
>
> {code}
> Notice the CR entity is removed, but also all of the characters immediately
> in front of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: [VOTE] release of 3.1.3
+1 Thanks, Scott! Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2057) Xerces will not build under Windows XP64 SP3
[ https://issues.apache.org/jira/browse/XERCESC-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15086027#comment-15086027 ] Vitaly Prapirny commented on XERCESC-2057: -- Set your PATH environment variable to point only to the Borland C++ Builder 5 Bin folder and remove other compilers from that variable, i.e PATH should be "C:\Program Files (x86)\Borland\BCB551\Bin" (I see BCB551 and BCC551 folders in your variable, not sure what actual path is) > Xerces will not build under Windows XP64 SP3 > > > Key: XERCESC-2057 > URL: https://issues.apache.org/jira/browse/XERCESC-2057 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.2 > Environment: Windows XP64 SP3 >Reporter: Andrew Tweddle > Fix For: 3.1.2 > > > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > cd XercesLib > copy ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.borland.hpp > ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.hpp > Fatal: Command arguments too long > Since Xerces is installed on the C: directory at the highest point it is not > possible to easily shorten any of the directory lengths to make this command > work, is this important, I don't know I am a newb to Xerces. Does this copy > need to be done or is there a quick copy that could be done to make the rest > of the build process work I have no idea. > regards sarason -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2057) Xerces will not build under Windows XP64 SP3
[ https://issues.apache.org/jira/browse/XERCESC-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15080364#comment-15080364 ] Vitaly Prapirny commented on XERCESC-2057: -- Borland C++ Builder 5 Update 1 compiler version is 5.5.1 so check your PATH variable carefully. > Xerces will not build under Windows XP64 SP3 > > > Key: XERCESC-2057 > URL: https://issues.apache.org/jira/browse/XERCESC-2057 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.2 > Environment: Windows XP64 SP3 >Reporter: Andrew Tweddle > Fix For: 3.1.2 > > > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > cd XercesLib > copy ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.borland.hpp > ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.hpp > Fatal: Command arguments too long > Since Xerces is installed on the C: directory at the highest point it is not > possible to easily shorten any of the directory lengths to make this command > work, is this important, I don't know I am a newb to Xerces. Does this copy > need to be done or is there a quick copy that could be done to make the rest > of the build process work I have no idea. > regards sarason -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2057) Xerces will not build under Windows XP64 SP3
[ https://issues.apache.org/jira/browse/XERCESC-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15076475#comment-15076475 ] Vitaly Prapirny commented on XERCESC-2057: -- BDS 4.0 is not the Borland C++ Builder 5 mentioned earlier. Seems like that compiler version is not supported by the Xerces-C++ 3.1.2. You can try to add an appropriate header file (see help on memcpy function in your BDS) into the Xerces_autoconf_config.borland.hpp. > Xerces will not build under Windows XP64 SP3 > > > Key: XERCESC-2057 > URL: https://issues.apache.org/jira/browse/XERCESC-2057 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.2 > Environment: Windows XP64 SP3 >Reporter: Andrew Tweddle > Fix For: 3.1.2 > > > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > cd XercesLib > copy ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.borland.hpp > ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.hpp > Fatal: Command arguments too long > Since Xerces is installed on the C: directory at the highest point it is not > possible to easily shorten any of the directory lengths to make this command > work, is this important, I don't know I am a newb to Xerces. Does this copy > need to be done or is there a quick copy that could be done to make the rest > of the build process work I have no idea. > regards sarason -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] [Commented] (XERCESC-2057) Xerces will not build under Windows XP64 SP3
[ https://issues.apache.org/jira/browse/XERCESC-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15075383#comment-15075383 ] Vitaly Prapirny commented on XERCESC-2057: -- What compiler and what compiler version are you using? As you can see, copy command arguments are not so long. Can you try the copy command without make utility and see if any errors are shown? Can you check that line endings are in DOS format in the Xerces-all.mak? > Xerces will not build under Windows XP64 SP3 > > > Key: XERCESC-2057 > URL: https://issues.apache.org/jira/browse/XERCESC-2057 > Project: Xerces-C++ > Issue Type: Bug > Components: Build >Affects Versions: 3.1.2 > Environment: Windows XP64 SP3 >Reporter: Andrew Tweddle > Fix For: 3.1.2 > > > MAKE Version 5.2 Copyright (c) 1987, 1998 Inprise Corp. > cd XercesLib > copy ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.borland.hpp > ..\..\..\..\..\src\xercesc\util\Xerces_autoconf_config.hpp > Fatal: Command arguments too long > Since Xerces is installed on the C: directory at the highest point it is not > possible to easily shorten any of the directory lengths to make this command > work, is this important, I don't know I am a newb to Xerces. Does this copy > need to be done or is there a quick copy that could be done to make the rest > of the build process work I have no idea. > regards sarason -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Difficulties in building Xerces c++ 3.1.2
Hi, Related links https://xerces.apache.org/xerces-c/migrate-archive-3.html#Migrateto300 http://stackoverflow.com/questions/3678396/xerces-c-migration-from-v2-x-to-v3-x Good luck! Vitaly Lakka, Matina (Nokia - GR/Athens) wrote: Hello, We are currently migrating from xerces 2.1.8 to 3.1.2 and while building our application with the new version of xerces we noticed that classes CDOM_EXPORT DOMBuilder and CDOM_EXPORT DOMWriter are missing. Could you please be so kind to tell us which are the new relevant classes? Many thanks in advance. Best, Matina Matina Lakka MBB OMP MP R 22 *NOKIA** *Promitheos Str. 12, 145 64 Nea Kifissia Athens - Greece mail to: matina.la...@nsn.com - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: [VOTE] release of 3.1.2
+1 Thanks, Scott! Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Multithreaded SAX parser
Hi, You can look at the ThreadTest project sources in the Xerces-C++ distribution. Good luck! Vitaly SonalG wrote: Hi, I want to parser multiple XML documents using SAX parser. I read somewhere on the net that you can create a pool of threads for this purpose but did not find sample code supporting it. One way is create a different parser object each time, but this is expensive operation and also calling initialize for each new parser object is expensive Does any one have any examples to share? My application is creating different thread which internally calls the parse method of the same parser object. This gives strange results as it is reading one file correctly but for the second XML file it just reads part of file and stops. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: regarding dom writer issue(very Urgent)
Hi, You can compare DOMPrint sample sources to get the idea. Good luck! Vitaly manish kumar burnwal wrote: Hi, I am migrating a C++ source code. earlier we were using Xerces-2.7,now we have migrated to xerces-c_3_0_1. In my old code i have domwriter and setfeature() and cansetfeature(),can you please guide me how to make it compatible with the new xerces,as i understand domwriter is no more supported. Please reply as soon as possible,it's very urgent. -- Manish Kumar - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Having a SAX2 parser parsing problem during the code migration from Xerces 2.8 to 3.1
Hi, pabna01 wrote: void characters(const XMLCh* const chars, const unsigned int length); The registered callbacks startElement and endElement are called during the processing when it encounters Sample Element tag.But characters method is not called when the xerces encounters the Sample element value data. Could you try this version: void characters(const XMLCh* const chars, const XMLSize_t length); Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Problem using static compile of xerces
Hi, AFAIK Xerces-C++ 3.0.1 source package contains VC6 project only for a DLL building and it is impossible to build a static library with it. A xerces-c_3.lib is not a static library. It is an import library for a xerces-c_3_0.dll. Good luck! Vitaly Stone, Timothy M wrote: Greetings, I have downloaded and compiled xerces 3.0.1. When I do this, it creates a xerces-c_3.lib (3.0MB) and a xerces-c_3_0.dll (2.3MB). If I compile my app (MSVC++ 6) using the DLL, then everything works fine. It compiles and runs correctly. I am trying to use the static version, so I don't have to have the DLL present when I run my app. When I try this, it still says I need the DLL at runtime. I then looked online, and saw it may be necessary to declare XERCES_STATIC_LIBRARY as a preprocessor definition, which I did. Unfortunately, when I do that, the project no longer compiles...I then get the following errors at link time: Help? Linking... parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgXercesUserAdoptsDOMDocument (?fgxercesuseradoptsdomdocum...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgXercesLoadSchema (?fgxercesloadsch...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgXercesUseCachedGrammarInParse (?fgxercesusecachedgrammarinpa...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgXercesSchemaFullChecking (?fgxercesschemafullcheck...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgXercesSchema (?fgxercessch...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMValidate (?fgdomvalid...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMElementContentWhitespace (?fgdomelementcontentwhitesp...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMNamespaces (?fgdomnamespa...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMEntities (?fgdomentit...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMDatatypeNormalization (?fgdomdatatypenormalizat...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMComments (?fgdomcomme...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static class xercesc_3_0::MemoryManager * xercesc_3_0::XMLPlatformUtils::fgMemoryManager (?fgmemorymana...@xmlplatformutils@xercesc_3_0@@2pavmemorymana...@2@A) parse_xml.obj : error LNK2001: unresolved external symbol public: static unsigned short const * const xercesc_3_0::XMLUni::fgDOMErrorHandler (?fgdomerrorhand...@xmluni@xercesc_3_0@@2QBGB) parse_xml.obj : error LNK2001: unresolved external symbol public: static char const * const xercesc_3_0::XMLUni::fgXercescDefaultLocale (?fgxercescdefaultloc...@xmluni@xercesc_3_0@@2QBDB) - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Where is DOMBuilder?
Hi,
http://xerces.apache.org/xerces-c/migrate-archive-3.html#DeprecatedAPI300
Good luck!
Vitaly
Hiroyuki Shimada wrote:
Hello,
I am using Xerces C++ 3.1.1 and writing following program.
But compiler says can't openxercesc/dom/DOMBuilder.hpp.
I can't find DOMBuilder.hpp in the Xerces C++ package.
Is DOMBuilder obsolete? Is there any other way? Please help me.
Thank you for your help.
#includeiostream
#includexercesc/dom/DOMBuilder.hpp
#includexercesc/dom/DOMDocument.hpp
#includexercesc/dom/DOMImplementation.hpp
#includexercesc/dom/DOMImplementationLS.hpp
#includexercesc/dom/DOMImplementationRegistry.hpp
#includexercesc/parsers/AbstractDOMParser.hpp
#includexercesc/util/PlatformUtils.hpp
try
{
XMLPlatformUtils::Initialize();
}
catch(...)
{
std::cerr Error;
}
const XMLCh gLS[] = { chLatin_L, chLatin_S, chNull };
DOMImplementation* impl
= DOMImplementationRegistry::getDOMImplementation(gLS);
DOMBuilder* parser
= ((DOMImplementationLS*)impl)-createDOMBuilder(
DOMImplementationLS::MODE_SYNCHRONOUS, 0);
... snip ...
--
Mail: shima...@din.or.jp
Home Page: http://www.din.or.jp/~shimaden/
Hiroyuki Shimada
--
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
-
To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org
For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: [VOTE]: Nomination of Mukul Gandhi for Xerces PMC Membership
+1 Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Problem writing large XML file
In my opinion custom serializer requires a small amount of simple code and more memory efficient in comparison with the code that use a general purpose serializer such as the DOM API or something else. Good luck! Vitaly Vladimir Loubenski wrote: My own serialization procedure can be workaround. But this approach will require large amount of low level coding (writing xml tags, replacement for some characters, etc.) ... Does exist some library that helps to implement such approach? Thank you in advance for any information. Regards, Vladimir. -Original Message- From: Vitaly Prapirny [mailto:m...@mebius.net] Sent: April 2, 2010 2:49 AM To: c-dev@xerces.apache.org Subject: Re: Problem writing large XML file Hi, Vladimir Loubenski wrote: I have large amount of data (more than computer RAM) that I need to wrote to XML file. How can I do that? It's not a problem for me to use another than DOM API but I can not find any. For example SAX only for reading. In most of the modern operating systems the memory a process can use is not bounded by RAM size. But if the data size is really huge (or for performance reasons) you could use you own serialization procedure instead of the DOM API. Traverse your data and write it out with xml tagging. And don't forget to replace some special characters with predefined entities like lt;, gt;, etc. Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Problem writing large XML file
Hi, Vladimir Loubenski wrote: I have large amount of data (more than computer RAM) that I need to wrote to XML file. How can I do that? It's not a problem for me to use another than DOM API but I can not find any. For example SAX only for reading. In most of the modern operating systems the memory a process can use is not bounded by RAM size. But if the data size is really huge (or for performance reasons) you could use you own serialization procedure instead of the DOM API. Traverse your data and write it out with xml tagging. And don't forget to replace some special characters with predefined entities like lt;, gt;, etc. Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: Help validating XML against an XSD?
Boris Kolpackov wrote: Hi Timothy, Stone, Timothy Mtst...@ida.org writes: Hm, I've given it some offort, but cannot seem to get it going. I have a .xsd and a .xml file, and I just want to test if the XML is compliant with the XSD. Seeing that this is becoming sort of a FAQ (though without a good answer), I have written a little post plus included a couple of examples that you may find useful: http://www.codesynthesis.com/~boris/blog/2010/03/15/validating-external-schemas-xerces-cxx/ Boris Another simple way to achieve the same is setting the fgXercesSchemaExternalSchemaLocation and fgXercesSchemaExternalNoNameSpaceSchemaLocation parameters (or using setExternalSchemaLocation and setExternalNoNamespaceSchemaLocation methods if available). Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: VOTE for 3.1.0
+1 Good luck! Vitaly Boris Kolpackov wrote: Hi, It has been almost two months since the release of 3.1.0 RC1 and I would like to propose that we release the final 3.1.0 in the next couple of days. Since we haven't uncovered any issues with the release candidate, the final release will be pretty much unchanged except for a few minor changes related to compiler warnings plus documentation updates (release notes, etc). Also, if you haven't tested 3.1.0 RC1 with your application(s), the next couple of days will be your last chance to do so. You can download the release candidate from this location: http://people.apache.org/builds/xerces/c/ Here is my +1 for the final release. Boris - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: VOTE for 3.1.0 release candidate 1
Hi, Boris Kolpackov wrote: BCC.551 projects are maintained actually. Just to make it clear: are you willing to test this project for the Xerces-C++ 3.1.0 release and make sure it is up-to-date, everything is workings, etc., as well as continue maintaining it after the 3.1.0 release? I'm willing to do all necessary actions for the 3.1.0 release (it seems that BCC.551 doesn't need any changes for this release). Can't promise the same for next releases though. Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: VOTE for 3.1.0 release candidate 1
+1 Boris Kolpackov wrote: Finally, there are a number of old, unsupported, and unmaintained project files in the projects/ directory. Namely, BCB6, BCC.551, and VC6. I would like to remove these. Let me know if you have any objections and are prepared to make sure they work for this release and to continue actively maintaining them for future releases. BCC.551 projects are maintained actually. Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: New Xerces Chair
Gareth Reakes wrote: Hey all, I have been with the Xerces project for a fair while now but recently I have not been able to devote enough time to the project. I can't see this changing any time soon and so I want to step down from being the chair of the PMC. I would also like to nominate Michael Glavassevich for the role. If anyone would like to suggest another person then please do. +1 for Michael +1 Thank you very much for all your work, Gareth. Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
Re: VOTE for the 3.0.1 release
+1 Good luck! Vitaly - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Commented: (XERCESC-1560) Problem building app that uses xerces
[ https://issues.apache.org/jira/browse/XERCESC-1560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668865#action_12668865 ] Vitaly Prapirny commented on XERCESC-1560: -- It's a Borland bug. Some discussion on this issue: http://marc.info/?t=12229416474r=1w=2 Problem building app that uses xerces - Key: XERCESC-1560 URL: https://issues.apache.org/jira/browse/XERCESC-1560 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.7.0 Environment: Borland C++ Builder 6 Reporter: Johnny Willemsen I try to build ACE/TAO/CIAO which uses xerces, I get the following errors. Solution seems to move memcpy out of the header file. Error E2268 C:\xerces-c-src_2_7_0\include\xercesc/framework/XMLBuffer.hpp 126: Call to undefined function 'memcpy' in function XMLBuffer::append(const wchar_t * const,const unsigned int) Error E2268 C:\xerces-c-src_2_7_0\include\xercesc/framework/XMLBuffer.hpp 144: Call to undefined function 'memcpy' in function XMLBuffer::append(const wchar_t * const) Error E2268 C:\xerces-c-src_2_7_0\include\xercesc/util/XMLString.hpp 1677: Call to undefined function 'memcpy' in function XMLString::moveChars(wchar_t * const,const wchar_t * const,const unsigned int) Error E2268 C:\xerces-c-src_2_7_0\include\xercesc/util/XMLString.hpp 1706: Call to undefined function 'memcpy' in function XMLString::replicate(const wchar_t * const,MemoryManager * const) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: c-dev-unsubscr...@xerces.apache.org For additional commands, e-mail: c-dev-h...@xerces.apache.org
[jira] Created: (XERCESC-1830) DOMPrint sample build with Borland compiler: Ambiguity between 'DOMDocument' and 'xercesc_3_0::DOMDocument
DOMPrint sample build with Borland compiler: Ambiguity between 'DOMDocument' and 'xercesc_3_0::DOMDocument -- Key: XERCESC-1830 URL: https://issues.apache.org/jira/browse/XERCESC-1830 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 3.0.0 Environment: Windows XP, Borland C++ Builder 5.0 Reporter: Vitaly Prapirny Priority: Trivial Error occured while building Xerces-C samples using BCC.551 project files: Error E2015 ..\..\..\..\..\samples\src\DOMPrint\DOMPrint.cpp 497: Ambiguity between 'DOMDocument' and 'xercesc_3_0::DOMDocument' in function main(int,char * *) The fix is trivial (svn diff): Index: projects/Win32/BCC.551/Xerces-all/DOMPrint/DOMPrint.mak === --- projects/Win32/BCC.551/Xerces-all/DOMPrint/DOMPrint.mak (revision 696930) +++ projects/Win32/BCC.551/Xerces-all/DOMPrint/DOMPrint.mak (working copy) @@ -23,7 +23,7 @@ PATHASM = .; PATHPAS = .; PATHRC = .; -USERDEFINES = _DEBUG;XERCES_NO_CONFIGURE_SUPPORT +USERDEFINES = _DEBUG;WIN32_LEAN_AND_MEAN;XERCES_NO_CONFIGURE_SUPPORT SYSDEFINES = _NO_VCL;_VIS_NOLIB;_RTLDLL INCLUDEPATH = ..\..\..\..\..\samples\src\DOMPrint;..\..\..\..\..\src LIBPATH = ..\..\..\..\..\samples\src\DOMPrint -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE for the 3.0.0 release
+1. Good luck! Boris Kolpackov wrote: Hi Folks, The second beta for the 3.0.0 release didn't uncover any major problems. There were a few issues discovered but those were fairly local and are fixed now. While I am still finalizing the documentation, I would like to proceed with the vote for the final 3.0.0 release. Here is my +1. Boris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Does Xerces support Serialize XML as canonical form?
[EMAIL PROTECTED] wrote: It seems Xerces currently doesn't support serializing XML as canonical form. Is there any plan to support that (http://www.w3.org/TR/xml-c14n)? Apache xml-security-c library provides implementation of canonicalised XML. Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Add Boris to PMC
+1 Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE - John Snelson commit access
+1 Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE for 3.0.0 beta
Boris Kolpackov wrote: I would therefore like to cut and publish a source code-only beta with the primary goal of letting all interested parties test the new build system. +1 from me. Thanks Boris! Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1768) xerces-c++ 2.8.0 fails to build when choosing IconvGNU as message loader on 64bit architecture
[ https://issues.apache.org/jira/browse/XERCESC-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12553606 ] Vitaly Prapirny commented on XERCESC-1768: -- Converting -1 to (nl_catd) should be better. xerces-c++ 2.8.0 fails to build when choosing IconvGNU as message loader on 64bit architecture -- Key: XERCESC-1768 URL: https://issues.apache.org/jira/browse/XERCESC-1768 Project: Xerces-C++ Issue Type: Bug Affects Versions: 2.8.0 Environment: Gentoo Linux 2007.0 amd64 Reporter: Tiziano Müller [...] MsgCatalogLoader.cpp: In constructor 'xercesc_2_8::MsgCatalogLoader::MsgCatalogLoader(const XMLCh*)': MsgCatalogLoader.cpp:103: error: cast from 'void*' to 'int' loses precision MsgCatalogLoader.cpp:104: error: cast from 'void*' to 'int' loses precision make[2]: *** [MsgCatalogLoader.o] Error 1 make[1]: *** [messageloaders] Error 2 make: *** [Util] Error 2 make: *** Waiting for unfinished jobs (C++) XSObject.o (C++) XSParticle.o (C++) XSSimpleTypeDefinition.o (C++) XSTypeDefinition.o (C++) XSValue.o (C++) XSWildcard.o (CP) /var/tmp/paludis/dev-libs/xerces-c-2.8.0/work/xerces-c-src_2_8_0/include/xercesc/framework/psvi I'd guess that this is also the reason for bug XERCESC-1586 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE - Boris Kolpackov commit access
+1 Good luck! Vitaly Gareth Reakes wrote: Hi all, Boris has put in an awful lot of work over the last couple of months culminating in well overdue release last week. I would like to propose he becomes a committer in recognition of this hard work. Here is my +1 Cheers, Gareth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE on 2.8 release
Boris Kolpackov wrote: I'd prefer https://issues.apache.org/jira/browse/XERCESC-1242 to be fixed in this release also. I and Alberto (who is a local regex guru ;-)) discussed applying this patch to 2.8.0. However, the changes are extensive and it is unclear what impact they will have on the performance of normal cases (short strings). After all the patch essentially substitutes program stack (which is quite fast) with a heap-based stack (which is quite slow). So we decided not to apply it to 2.8.0. It is however in 3.0.0 which will hopefully be released soon. To make situation more clear here some numbers from my performance test (modified SAX2Count -v=always -f -p which parsing MemBufInputSource many times, cached grammar, simple schema, simple regex [A-Z]*): 1 element with 1 attribute - BCB5 attr. lengthperformance change (gain if +) 1 +5.03% 1000-5.67% 100 -3.61% 10 -1.56% 1 element with 1 attribute - gcc 4.1.2 attr. lengthperformance change (gain if +) 10 -13.05% 1 +0.8% 1000-12.9% 100 -7.27% 10 -4.84% 128 elements with 1 attribute - BCB5 attr. lengthperformance change (gain if +) 1 +3.37% 1000-7.31% 100 -13.78% 10 -23.09% 128 elements with 1 attribute - gcc 4.1.2 attr. lengthperformance change (gain if +) 1 -5.51% 1000-15.67% 100 -19.92% 10 -20.77% So you are right, there is some performance loss. We should see less performance change in real life applications though. Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE on 2.8 release
I'd prefer https://issues.apache.org/jira/browse/XERCESC-1242 to be fixed in this release also. But +1 from me anyway. Good luck! Vitaly Gareth Reakes wrote: Hey all, RC1 has been used and tested by a fair number of people and a few minor issues came up. These have been fixed and the docs have been updated. The full list of changes are: * Documentation updates for 2.8.0 * Change the library extension on PH-UX/IA64 from .sl to .so * Updated the RPM spec file with support for 64 bit builds and Solaris * Make packageSources.pl split the archive into -src and -tools * Add multi-thread options and defines only when building a multi-threaded library * Fix for a regression in regex code Based on these limited changes I don't think we need an RC2. The website will also (finally) change to xerces.apache.org/xerces-c/. Once again I woudl like to thank Boris and all the other people have helped test. Here is my +1 for a release that will hopefully happen this Friday. Gareth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1242) Validation with restricted base type string crashes with a certain amount of chars
[
https://issues.apache.org/jira/browse/XERCESC-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12522945
]
Vitaly Prapirny commented on XERCESC-1242:
--
Verified. Thank you very much, Alberto! Your fixes are OK. And what about 2.7
branch?
Validation with restricted base type string crashes with a certain amount of
chars
--
Key: XERCESC-1242
URL: https://issues.apache.org/jira/browse/XERCESC-1242
Project: Xerces-C++
Issue Type: Bug
Components: Validating Parser (Schema) (Xerces 1.5 or up only)
Affects Versions: 2.2.0
Environment: W2K / Borland 5.3 Compiler
Reporter: Hakan Abaka
Attachments: xercesc-2_5_0-regexp.patch.gz,
xercesc-2_5_0-regexp1.patch.gz
A simpleType of base type string with a restriction leads to an access
violation during validation under certain circumstances. The ristriction is a
regular expression and has the pattern ([A-F0-9]{2})*. The attribute is of
that restricted type and has a length greater than 28859 characters.
Use without restriction works properly.
( Last function called is nextCh in module RegularExpression.cpp )
xsd file:
?xml version=1.0 encoding=UTF-8?
xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema;
xsd:element name=TestElement type=tTestElement/
xsd:complexType name=tTestElement
xsd:attribute name=Name type=tHexBinary/
/xsd:complexType
xsd:simpleType name=tHexBinary
xsd:restriction base=xsd:string
xsd:pattern value=([A-F0-9]{2})*/
/xsd:restriction
/xsd:simpleType
/xsd:schema
xml file:
?xml version=1.0 encoding=UTF-8?
TestElement xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
Name=1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1FFF1F1F1
[jira] Updated: (XERCESC-1737) Patches for the 2.8.0 release
[ https://issues.apache.org/jira/browse/XERCESC-1737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Prapirny updated XERCESC-1737: - Attachment: bcc551.patch.gz Projects\Win32\BCC.551\Xerces-all\XercesLib\afxres.h should be renamed to winres.h to successfully build out of the box Patches for the 2.8.0 release - Key: XERCESC-1737 URL: https://issues.apache.org/jira/browse/XERCESC-1737 Project: Xerces-C++ Issue Type: Improvement Reporter: Boris Kolpackov Attachments: bcc551.patch.gz, heap-v2.patch, heap.patch, https.patch, patches-2.7.tar.gz, static.patch, version-change.patch I have prepared a patch for the following issues: * Support for g++ on AIX and HP-UX. * Auto-detection of aCC6 vs aCC3 in runConfigure. * Verbose mode (gmake VERBOSE=1) * Changed optimization level for GNU/Linux from -O to -O2 * Fixes for 64 bit and SO_NAME options. * Project files for VS 2005. * Support for 64 bit Windows build. * Optimized DOM parsing (25-30% improvement). It consists of the following parts: ChangeLog- description of the changes. xerces-2.7.patch - patch against the current xerces-2.7 branch VC8 - MSVC8 project files, should be copied to Projects/Win32/ I have tested this code with most of the platforms mentioned in the Xerces-C++ 2.8.0 release plan email I send the other day. I would appreciate it if one of the Xerces-C++ developers review and commit this patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Xerces-C++ 2.8.0 release plan
Hi, Boris Kolpackov wrote: I therefore would like to volunteer as a release manager for 2.8.0. Once 2.8.0 is released, I am prepared to act as a release manager and push for 3.0. I think it would be great contribution. Don't you think 2.7.1 would be better version number for 2.7.0 with bug fixes? Are there any binary incompatibilities known? Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (XERCESC-1708) Regex pattern on long content results in stack overflow
[ https://issues.apache.org/jira/browse/XERCESC-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaly Prapirny updated XERCESC-1708: - Attachment: xercesc-2_7_0-regexp.patch.gz xercesc-2_7_0-regexp.patch.gz Since this issue is not marked as the duplicate of the http://issues.apache.org/jira/browse/XERCESC-1242 yet I propose just the same fix as in XERCESC-1242 . Hope this fix helps on most of regex stack overflow cases. Regex pattern on long content results in stack overflow --- Key: XERCESC-1708 URL: https://issues.apache.org/jira/browse/XERCESC-1708 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (Schema) (Xerces 1.5 or up only) Affects Versions: 2.7.0 Environment: any Reporter: Boris Kolpackov Attachments: xercesc-2_7_0-regexp.patch.gz This seems to be the same bug as https://issues.apache.org/jira/browse/XERCESJ-589. The original report is archived here: http://marc.info/?t=117892039300010r=1w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inconsistencies in unsigned int to XMLSize_t changes
Hi Alberto, Alberto Massari wrote: the change was intentional; XMLSize_t should be used when dealing with a number that expresses the size of a memory buffer (i.e. it complements a pointer), while unsigned int/unsigned long are to be used when expressing standalone numbers (i.e. the number of items in a vector/list, the line/column number). The number of items in a container is the size of it, isn't it? Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1708) Regex pattern on long content results in stack overflow
[ https://issues.apache.org/jira/browse/XERCESC-1708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497743 ] Vitaly Prapirny commented on XERCESC-1708: -- This seems to be the duplicate of the http://issues.apache.org/jira/browse/XERCESC-1242. Regex pattern on long content results in stack overflow --- Key: XERCESC-1708 URL: https://issues.apache.org/jira/browse/XERCESC-1708 Project: Xerces-C++ Issue Type: Bug Components: Validating Parser (Schema) (Xerces 1.5 or up only) Affects Versions: 2.7.0 Environment: any Reporter: Boris Kolpackov This seems to be the same bug as https://issues.apache.org/jira/browse/XERCESJ-589. The original report is archived here: http://marc.info/?t=117892039300010r=1w=2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE - Move XML Commons to Xerces
+1 Good luck ! Vitaly Gareth Reakes wrote: Start again including all the right emails! Gareth Gareth Reakes [EMAIL PROTECTED] wrote on 10/26/2006 07:04:14 PM: Hey all, As per discussions that have been happening over the last few months Xerces would like to take responsibility for XML Commons. This is an official vote for that subject. + 1 from me for Xerces PMC +1 from me XML PMC Regards, Gareth -- Gareth Reakes, Managing Director Embrace Mobile +44-1865-811197 http://www.embracemobile.com -- Gareth Reakes, Managing Director Embrace Mobile +44-1865-811197 http://www.embracemobile.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Building a DOM tree by parsing a memory buffer
Hi, Gian Luca Rubini wrote: my goal is to get a DOM tree by parsing a memory buffer. You could use XercesDOMParser with MemBufInputSource. Good luck ! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (XERCESC-1615) Build Error with C++ Builder 6.
[ http://issues.apache.org/jira/browse/XERCESC-1615?page=comments#action_12423032 ] Vitaly Prapirny commented on XERCESC-1615: -- Try third suggestion (BCC.551 project files) :) or rename Projects\Win32\BCB6\Xerces-all\XercesLib\afxres.h to winres.h Build Error with C++ Builder 6. --- Key: XERCESC-1615 URL: http://issues.apache.org/jira/browse/XERCESC-1615 Project: Xerces-C++ Issue Type: Bug Components: Build Affects Versions: 2.7.0 Environment: Windows XP. BorlandC++ Builder Version 6.0 Reporter: Mike Evans Build fails with following error mesages: --- [RC Error] Version.rc(10): [RC Fatal Error] Version.rc(1): Compile [C++] XTemplateComparator.cpp(1): [C++ Fatal Error] XTemplateComparator.cpp(1): F1009 Unable to open input file 'E:\Documents and Settings\Mike Evans\My Documents\projects\xerces-c-src_2_7_0\src\xercesc\internal\XTemplateComparator.cpp' - The file: XTemplateComparator.cpp does not exist in the source tree. Source downloaded 2006-07-10 Version.rc, line 10 is: #include winres.h -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Toolkit on ZOS
[EMAIL PROTECTED] wrote:
I didnt find any implementation of this Method in classes derived from
this. I have gone through hpp files coming with XML Toolkit.
Implementation has not been stored in hpp files usually.
I have tried following things in my cpp program but it gives me DOM
exception saying that *The implementation does not support the
requested type of object or operation*
DOMElement* root = doc-getDocumentElement();
try {
walker = doc-createTreeWalker(root,DOMNodeFilter::SHOW_ALL, NULL, true);
}
*catch (const DOMException toCatch) {*
AFAIK createTreeWalker throws this exception when first parameter is
NULL. Could you check what getDocumentElement returns ?
Good luck !
Vitaly
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Toolkit on ZOS
[EMAIL PROTECTED] wrote: As per your instructions, I was able to Build samples from Toolkit successfully after following instructions given. Similar way I was following steps for my program. But Program got crashed this time also. I suppose that your program use xerces incorrectly. Look at samples and change your program according to samples. Good luck ! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Toolkit on ZOS
[EMAIL PROTECTED] wrote: * *Compile Step : c++ -+ -W c,dll -I/usr/lpp/ixm/IBM/xml4c-5_5/include -DXERCES_TMPLSINC -o bun1.o bun1.cpp /usr/lpp/ixm/IBM/xml4c-5_5/lib/libxerces-c2_6_0.x* * *Link Step : c++ -+ -v -V -W l,dll -I/usr/lpp/ixm/IBM/xml4c-5_5/include -DXERCES_TMPLSINC -o bun bun1.o /usr/lpp/ixm/IBM/xml4c-5_5/lib/libxerces-c2_6_0.dll /usr/lpp/ixm/IBM/xml4c-5_5/lib/libxerces-c2_6_0.x 1out 2err* You didn't povide content of out and err files. But there are some suggestions: - compile step does not need import library (libxerces-c2_6_0.x) - link step does not need shared library (libxerces-c2_6_0.dll) Good luck ! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Toolkit on ZOS
[EMAIL PROTECTED] wrote: When I try to just compile my CPP program with following command c++ -+ -W c,dll -I/usr/lpp/ixm/IBM/xml4c-5_5/include -DXERCES_TMPLSINC -o bun1.o bun1.cpp ( without libxerces-c2_6_0.x ) as per your suggestion it gives me following errors You have to use -c switch if you want execute only compile step without linking. Your command compile and link executable with name bun1.o and import library (libxerces-c2_6_0.x) must be used for that. Good luck ! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Toolkit on ZOS
[EMAIL PROTECTED] wrote: As suggested, I tried to create Executable from CPP program with following command *c++ -+ -v -V -W c,dll -I/usr/lpp/ixm/IBM/xml4c-5_5/include -o bun bun1.cpp /usr/* *lpp/ixm/IBM/xml4c-5_5/lib/libxerces-c2_6_0.x 1out 2err* This step has created Executable with name 'bun'. But now when I try to run bun executable, it gets crashed and getting message like process Killed If you'd provide full crash message from your system it would be more helpful. I suppose that system cannot find libxerces-c2_6_0.dll. You could try to run your executable when /usr/lpp/ixm/IBM/xml4c-5_5/lib/ is your current directory. If it is not the case then I suggest your look at the Toolkit samples first. If it works - do the same things with your program. If the samples doesn't work then contact the Toolkit support team as suggested by David Cargill. Good luck! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML Toolkit on ZOS
[EMAIL PROTECTED] wrote: When I run bun from my directory like given below, it crashes (TCSMVSY)MCUAMR /usr/mcu/mcuamr ./bun *[1] + Done(137) ./bun* * 83886286 Killed ./bun* It doesnt give me the any other details. Could you give me some reasons for the same ? I can't add anything. Could you try suggestions from my previous message? Good luck ! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Location XERCES Library for ZOS
[EMAIL PROTECTED] wrote: Trying to build xerces-c library with Sources from Apache and Binaries for Z/os from IBM Toolkit. As I understand this you shouldn't try to build library from sources because XML Toolkit for z/OS contains all binaries needed. So sources from Apache can be omitted. Files inside directory SMPRELF are -rwxr-xr-x 1 MCUAMR MCU 258048 Jun 6 2005 DEPT42RJ.IBM.HXML160.F1.pax.Z -rwxr-xr-x 1 MCUAMR MCU 121895424 Jun 6 2005 DEPT42RJ.IBM.HXML160.F2.pax.Z -rwxr-xr-x 1 MCUAMR MCU 31352832 Jun 6 2005 DEPT42RJ.IBM.HXML160.F3.pax.Z -rwxr-xr-x 1 MCUAMR MCU 290304 Jun 6 2005 DEPT42RJ.IBM.HXML170.F1.pax.Z -rwxr-xr-x 1 MCUAMR MCU 94606848 Jun 6 2005 DEPT42RJ.IBM.HXML170.F2.pax.Z -rwxr-xr-x 1 MCUAMR MCU 38481408 Jun 6 2005 DEPT42RJ.IBM.HXML170.F3.pax.Z -rwxr-xr-x 1 MCUAMR MCU 516096 Jun 6 2005 DEPT42RJ.IBM.HXML180.F1.pax.Z -rwxr-xr-x 1 MCUAMR MCU 141571584 Jun 6 2005 DEPT42RJ.IBM.HXML180.F2.pax.Z -rwxr-xr-x 1 MCUAMR MCU 76027392 Jun 6 2005 DEPT42RJ.IBM.HXML180.F3.pax.Z The V1.8 download package contains V1.6, V1.7, and V1.8 installations. * Is this process correct one ? * Do I need to run pax -rvf command on all these files ( .Z) also ? * Finally for all other platforms like Solaris ( for building XML Library ) , we do have bin directory which contains some binary files specific to that Platform. Now here do i need to keep binaries in some dataset Or Unix subsystem ? Some useful info: - V1.8 Program Directory (contains installation information) http://www-03.ibm.com/servers/eserver/zseries/software/xml/pdf/xmlpd1_8.pdf - V1.8 XML Toolkit for z/OS User's Guide http://www-03.ibm.com/servers/eserver/zseries/software/xml/pdf/ug_v1r8.pdf Hope this helps. Good luck ! Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Fwd: Re: vote for new PMC members] - voters reply to this instead!
+1 on both Good luck ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Build statically linkable lib for Borland compiler?
Hi Randall, Sorry for delay. I'd successfully build static version of xerces 2.6.0 library with this slightly modified XercesLib.mak, and tests and samples executes reasonably well. This version use dynamic Borland runtime library, so you have to modify this makefile even more if you want to use static RTL. Drop attached file to Projects\Win32\BCC.551\Xerces-all\XercesLib and try. I have no time to answer to every question in your message now, sorry. Good luck ! # --- !if !$d(BCB) BCB = $(MAKEDIR)\.. !endif # --- TARGETPATH=..\..\..\..\..\Build\Win32\BCC.551 PROJECT = $(TARGETPATH)\xerces-bor_$(XERCESVER).lib !if $d(WITHDEPRDOM) DEPRDOM_PATH=..\..\..\..\..\src\xercesc\dom\deprecated DEPRDOM_DEFINE=;PROJ_DEPRECATED_DOM DEPRDOM_OBJFILES = \ $(TARGETPATH)\obj\AttrImpl.obj \ $(TARGETPATH)\obj\AttrMapImpl.obj \ $(TARGETPATH)\obj\AttrNSImpl.obj \ $(TARGETPATH)\obj\CDATASectionImpl.obj \ $(TARGETPATH)\obj\CharacterDataImpl.obj \ $(TARGETPATH)\obj\ChildNode.obj \ $(TARGETPATH)\obj\CommentImpl.obj \ $(TARGETPATH)\obj\DeepNodeListImpl.obj \ $(TARGETPATH)\obj\DocumentFragmentImpl.obj \ $(TARGETPATH)\obj\DocumentImpl.obj \ $(TARGETPATH)\obj\DocumentTypeImpl.obj \ $(TARGETPATH)\obj\DomMemDebug.obj \ $(TARGETPATH)\obj\DOMParser.obj \ $(TARGETPATH)\obj\DOMString.obj \ $(TARGETPATH)\obj\DOM_Attr.obj \ $(TARGETPATH)\obj\DOM_CDATASection.obj \ $(TARGETPATH)\obj\DOM_CharacterData.obj \ $(TARGETPATH)\obj\DOM_Comment.obj \ $(TARGETPATH)\obj\DOM_Document.obj \ $(TARGETPATH)\obj\DOM_DocumentFragment.obj \ $(TARGETPATH)\obj\DOM_DocumentType.obj \ $(TARGETPATH)\obj\DOM_DOMException.obj \ $(TARGETPATH)\obj\DOM_DOMImplementation.obj \ $(TARGETPATH)\obj\DOM_Element.obj \ $(TARGETPATH)\obj\DOM_Entity.obj \ $(TARGETPATH)\obj\DOM_EntityReference.obj \ $(TARGETPATH)\obj\DOM_NamedNodeMap.obj \ $(TARGETPATH)\obj\DOM_Node.obj \ $(TARGETPATH)\obj\DOM_NodeFilter.obj \ $(TARGETPATH)\obj\DOM_NodeIterator.obj \ $(TARGETPATH)\obj\DOM_NodeList.obj \ $(TARGETPATH)\obj\DOM_Notation.obj \ $(TARGETPATH)\obj\DOM_ProcessingInstruction.obj \ $(TARGETPATH)\obj\DOM_Range.obj \ $(TARGETPATH)\obj\DOM_RangeException.obj \ $(TARGETPATH)\obj\DOM_Text.obj \ $(TARGETPATH)\obj\DOM_TreeWalker.obj \ $(TARGETPATH)\obj\DOM_XMLDecl.obj \ $(TARGETPATH)\obj\DStringPool.obj \ $(TARGETPATH)\obj\ElementDefinitionImpl.obj \ $(TARGETPATH)\obj\ElementImpl.obj \ $(TARGETPATH)\obj\ElementNSImpl.obj \ $(TARGETPATH)\obj\EntityImpl.obj \ $(TARGETPATH)\obj\EntityReferenceImpl.obj \ $(TARGETPATH)\obj\NamedNodeMapImpl.obj \ $(TARGETPATH)\obj\NodeIDMap.obj \ $(TARGETPATH)\obj\NodeImpl.obj \ $(TARGETPATH)\obj\NodeIteratorImpl.obj \ $(TARGETPATH)\obj\NodeListImpl.obj \ $(TARGETPATH)\obj\NodeVector.obj \ $(TARGETPATH)\obj\NotationImpl.obj \ $(TARGETPATH)\obj\ParentNode.obj \ $(TARGETPATH)\obj\ProcessingInstructionImpl.obj \ $(TARGETPATH)\obj\RangeImpl.obj \ $(TARGETPATH)\obj\RefCountedImpl.obj \ $(TARGETPATH)\obj\TextImpl.obj \ $(TARGETPATH)\obj\TreeWalkerImpl.obj \ $(TARGETPATH)\obj\XMLDeclImpl.obj !endif OBJFILES = $(TARGETPATH)\obj\XercesLib.obj \ $(TARGETPATH)\obj\Win32PlatformUtils.obj \ $(TARGETPATH)\obj\InMemMsgLoader.obj \ $(TARGETPATH)\obj\Win32TransService.obj \ $(TARGETPATH)\obj\BinHTTPURLInputStream.obj \ $(TARGETPATH)\obj\WinSockNetAccessor.obj \ $(TARGETPATH)\obj\ASCIIRangeFactory.obj \ $(TARGETPATH)\obj\BlockRangeFactory.obj \ $(TARGETPATH)\obj\BMPattern.obj \ $(TARGETPATH)\obj\CharToken.obj \ $(TARGETPATH)\obj\ClosureToken.obj \ $(TARGETPATH)\obj\ConcatToken.obj \ $(TARGETPATH)\obj\ConditionToken.obj \ $(TARGETPATH)\obj\Match.obj \ $(TARGETPATH)\obj\ModifierToken.obj \ $(TARGETPATH)\obj\Op.obj \ $(TARGETPATH)\obj\OpFactory.obj \ $(TARGETPATH)\obj\ParenToken.obj \ $(TARGETPATH)\obj\ParserForXMLSchema.obj \ $(TARGETPATH)\obj\RangeFactory.obj \ $(TARGETPATH)\obj\RangeToken.obj \ $(TARGETPATH)\obj\RangeTokenMap.obj \ $(TARGETPATH)\obj\RegularExpression.obj \ $(TARGETPATH)\obj\RegxParser.obj \ $(TARGETPATH)\obj\RegxUtil.obj \ $(TARGETPATH)\obj\StringToken.obj \ $(TARGETPATH)\obj\Token.obj \ $(TARGETPATH)\obj\TokenFactory.obj \ $(TARGETPATH)\obj\UnicodeRangeFactory.obj \ $(TARGETPATH)\obj\UnionToken.obj \ $(TARGETPATH)\obj\XMLRangeFactory.obj \ $(TARGETPATH)\obj\XMLUniCharacter.obj \ $(TARGETPATH)\obj\Base64.obj \ $(TARGETPATH)\obj\BinFileInputStream.obj \ $(TARGETPATH)\obj\BinInputStream.obj \ $(TARGETPATH)\obj\BinMemInputStream.obj \ $(TARGETPATH)\obj\BitSet.obj \ $(TARGETPATH)\obj\HashPtr.obj \ $(TARGETPATH)\obj\HashXMLCh.obj \
