You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Paul Kinnucan <pa...@mathworks.com> on 2020/07/24 21:53:49 UTC
Xalan 1.12 samples and tests fail to build on Linux and the Mac
Hi,
The Xalan 1.12 samples and tests fail to build on Linux and the Mac. The reason is that the cmake build infrastructure tries to output the sample and test binaries at the top level of the samples and Tests directories, respectively. For example, the samples directory has the following structure:
samples
ApacheModduleXSLT
CompileStylesheet
DocumentBuilder
EntityResolver
ExternalFunction
…
The Xalan build infrastructure tries to create the sample executable in the root of the samples directory. This leads to a naming conflict. For example, the build intrastructure tells the linker to output the ExternalFunction executable at the root of the samples directory. The linker open function fails with the error message
[ 93%] Building CXX object src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o
cd /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath && /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++ -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -std=gnu++14 -o CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp
/mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: fatal error: ExternalFunction: open: Is a directory
I noticed that Xerces-c stores the source for its tests and samples in a src subdirectory but creates the executables at the top of the directory e.g.,
samples
src
CreateDOMDocument
CreateDOMDocument
This avoids the naming conflict.
The Xalan-c samples and tests build without issue on Windows.
Thanks for creating a version of Xalan-c that is easy to build on all major platforms.
Regards,
Paul
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Posted by Roger Leigh <rl...@codelibre.net>.
Hi Paul,
That's understood, but if you have the possibility of creating the
temporary build directory *inside* the xalan-c source directory, would
that be workable? Then just run "cmake .."
Kind regards,
Roger
On 27/07/2020 12:56, Paul Kinnucan wrote:
>
> Hi Roger,
>
> Building in a separate build directory is not an option for me because
> I have to use my employer’s makefile harness for deploying cmake-based
> third-party applications. I cannot alter this harness.
>
> My colleagues and I have decided to forego the xalan-c tests and
> samples for the time being. We will include them when the 1.13 release
> becomes available.
>
> Regards,
>
> Paul
>
> *From:* Roger Leigh <rl...@codelibre.net>
> *Sent:* Sunday, July 26, 2020 3:35 PM
> *To:* dev@xalan.apache.org
> *Subject:* Re: Xalan 1.12 samples and tests fail to build on Linux and
> the Mac
>
> Hi Paul,
>
> All you have to do is make a temporary build directory and run cmake
> from there, for example:
>
> mkdir build
>
> cd build
>
> cmake <options> /path/to/xalan-c
>
> and it will then build. That /should/ work, because that's what the
> CI build does and that's working just fine:
>
> https://github.com/apache/xalan-c/blob/master/scripts/ci-travis#L25
>
> If you can get that working, hopefully it will be a workaround until
> this is fixed in the next release.
>
> Kind regards,
>
> Roger
>
> On 26/07/2020 15:01, Paul Kinnucan wrote:
>
> Hi Roger,
>
> Thanks for the suggestions.
>
> I tried unsuccessfully to get cmake to use a different build
> directory. I am new to cmake so I was guessing what I needed to do
> and my many guesses were wrong.
>
> I am going to try moving the sample and example source directories
> into src directories below the top directories. This seems to me
> to require the fewest changes to the cmake build and test scripts
> for the samples and tests. All I have to do is change the location
> of the sources in the add_executable commands. The rest of the
> script should work as is to build and test the executables in the
> top directories.
>
> I’ll let you know how I fare.
>
> Regards,
>
> Paul
>
> *From:* Roger Leigh <rl...@codelibre.net>
> <ma...@codelibre.net>
> *Sent:* Saturday, July 25, 2020 4:32 PM
> *To:* dev@xalan.apache.org <ma...@xalan.apache.org>
> *Subject:* Re: Xalan 1.12 samples and tests fail to build on Linux
> and the Mac
>
> Hi Paul,
>
> A quick workaround to try: use a separate build directory then
> you'll avoid the naming conflicts.
>
> We will absolutely need to fix this. I copied the existing
> convention but I agree that adopting the Xerces-C++ strategy will
> be a better solution. See
> https://issues.apache.org/jira/browse/XALANC-811
> <https://issues.apache.org/jira/browse/XALANC-811> which I created
> to track this. An alternative approach would be to deliberately
> forbid in-source builds and require a separate build directory.
>
> Kind regards,
>
> Roger
>
> On 24/07/2020 22:53, Paul Kinnucan wrote:
>
> Hi,
>
> The Xalan 1.12 samples and tests fail to build on Linux and
> the Mac. The reason is that the cmake build infrastructure
> tries to output the sample and test binaries at the top level
> of the samples and Tests directories, respectively. For
> example, the samples directory has the following structure:
>
> samples
>
> ApacheModduleXSLT
>
> CompileStylesheet
>
> DocumentBuilder
> EntityResolver
>
> ExternalFunction
>
> …
>
> The Xalan build infrastructure tries to create the sample
> executable in the root of the samples directory. This leads to
> a naming conflict. For example, the build intrastructure tells
> the linker to output the ExternalFunction executable at the
> root of the samples directory. The linker open function fails
> with the error message
>
> [ 93%] Building CXX object
> src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o
>
> cd
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath
> &&
> /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++
> -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport
> -isystem
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include
> -isystem
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include
> -O2 -pipe -pthread
> -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox=
> -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual
> -Wctor-dtor-privacy -Wextra -Wformat=2 -Wmissing-declarations
> -Wno-long-long -Woverlength-strings -Woverloaded-virtual
> -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable
> -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -O2
> -pipe -pthread
> -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox=
> -fPIC -std=c++11 -std=gnu++14 -o
> CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp
>
> /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
> fatal error: ExternalFunction: open: Is a directory
>
> I noticed that Xerces-c stores the source for its tests and
> samples in a src subdirectory but creates the executables at
> the top of the directory e.g.,
>
> samples
>
> src
>
> CreateDOMDocument
>
> CreateDOMDocument
>
> This avoids the naming conflict.
>
> The Xalan-c samples and tests build without issue on Windows.
>
> Thanks for creating a version of Xalan-c that is easy to build
> on all major platforms.
>
> Regards,
>
> Paul
>
> Sent from Mail
> <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
>
RE: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Posted by Paul Kinnucan <pa...@mathworks.com>.
Hi Roger,
Building in a separate build directory is not an option for me because I have to use my employer's makefile harness for deploying cmake-based third-party applications. I cannot alter this harness.
My colleagues and I have decided to forego the xalan-c tests and samples for the time being. We will include them when the 1.13 release becomes available.
Regards,
Paul
From: Roger Leigh <rl...@codelibre.net>
Sent: Sunday, July 26, 2020 3:35 PM
To: dev@xalan.apache.org
Subject: Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Hi Paul,
All you have to do is make a temporary build directory and run cmake from there, for example:
mkdir build
cd build
cmake <options> /path/to/xalan-c
and it will then build. That /should/ work, because that's what the CI build does and that's working just fine:
https://github.com/apache/xalan-c/blob/master/scripts/ci-travis#L25<https://github.com/apache/xalan-c/blob/master/scripts/ci-travis#L25>
If you can get that working, hopefully it will be a workaround until this is fixed in the next release.
Kind regards,
Roger
On 26/07/2020 15:01, Paul Kinnucan wrote:
Hi Roger,
Thanks for the suggestions.
I tried unsuccessfully to get cmake to use a different build directory. I am new to cmake so I was guessing what I needed to do and my many guesses were wrong.
I am going to try moving the sample and example source directories into src directories below the top directories. This seems to me to require the fewest changes to the cmake build and test scripts for the samples and tests. All I have to do is change the location of the sources in the add_executable commands. The rest of the script should work as is to build and test the executables in the top directories.
I'll let you know how I fare.
Regards,
Paul
From: Roger Leigh <rl...@codelibre.net>
Sent: Saturday, July 25, 2020 4:32 PM
To: dev@xalan.apache.org<ma...@xalan.apache.org>
Subject: Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Hi Paul,
A quick workaround to try: use a separate build directory then you'll avoid the naming conflicts.
We will absolutely need to fix this. I copied the existing convention but I agree that adopting the Xerces-C++ strategy will be a better solution. See https://issues.apache.org/jira/browse/XALANC-811<https://issues.apache.org/jira/browse/XALANC-811> which I created to track this. An alternative approach would be to deliberately forbid in-source builds and require a separate build directory.
Kind regards,
Roger
On 24/07/2020 22:53, Paul Kinnucan wrote:
Hi,
The Xalan 1.12 samples and tests fail to build on Linux and the Mac. The reason is that the cmake build infrastructure tries to output the sample and test binaries at the top level of the samples and Tests directories, respectively. For example, the samples directory has the following structure:
samples
ApacheModduleXSLT
CompileStylesheet
DocumentBuilder
EntityResolver
ExternalFunction
...
The Xalan build infrastructure tries to create the sample executable in the root of the samples directory. This leads to a naming conflict. For example, the build intrastructure tells the linker to output the ExternalFunction executable at the root of the samples directory. The linker open function fails with the error message
[ 93%] Building CXX object src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o
cd /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath && /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++ -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -std=gnu++14 -o CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp
/mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: fatal error: ExternalFunction: open: Is a directory
I noticed that Xerces-c stores the source for its tests and samples in a src subdirectory but creates the executables at the top of the directory e.g.,
samples
src
CreateDOMDocument
CreateDOMDocument
This avoids the naming conflict.
The Xalan-c samples and tests build without issue on Windows.
Thanks for creating a version of Xalan-c that is easy to build on all major platforms.
Regards,
Paul
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Posted by Roger Leigh <rl...@codelibre.net>.
Hi Paul,
All you have to do is make a temporary build directory and run cmake
from there, for example:
mkdir build
cd build
cmake <options> /path/to/xalan-c
and it will then build. That /should/ work, because that's what the CI
build does and that's working just fine:
https://github.com/apache/xalan-c/blob/master/scripts/ci-travis#L25
If you can get that working, hopefully it will be a workaround until
this is fixed in the next release.
Kind regards,
Roger
On 26/07/2020 15:01, Paul Kinnucan wrote:
>
> Hi Roger,
>
> Thanks for the suggestions.
>
> I tried unsuccessfully to get cmake to use a different build
> directory. I am new to cmake so I was guessing what I needed to do and
> my many guesses were wrong.
>
> I am going to try moving the sample and example source directories
> into src directories below the top directories. This seems to me to
> require the fewest changes to the cmake build and test scripts for the
> samples and tests. All I have to do is change the location of the
> sources in the add_executable commands. The rest of the script should
> work as is to build and test the executables in the top directories.
>
> I’ll let you know how I fare.
>
> Regards,
>
> Paul
>
> *From:* Roger Leigh <rl...@codelibre.net>
> *Sent:* Saturday, July 25, 2020 4:32 PM
> *To:* dev@xalan.apache.org
> *Subject:* Re: Xalan 1.12 samples and tests fail to build on Linux and
> the Mac
>
> Hi Paul,
>
> A quick workaround to try: use a separate build directory then you'll
> avoid the naming conflicts.
>
> We will absolutely need to fix this. I copied the existing convention
> but I agree that adopting the Xerces-C++ strategy will be a better
> solution. See https://issues.apache.org/jira/browse/XALANC-811
> <https://issues.apache.org/jira/browse/XALANC-811> which I created to
> track this. An alternative approach would be to deliberately forbid
> in-source builds and require a separate build directory.
>
> Kind regards,
>
> Roger
>
> On 24/07/2020 22:53, Paul Kinnucan wrote:
>
> Hi,
>
> The Xalan 1.12 samples and tests fail to build on Linux and the
> Mac. The reason is that the cmake build infrastructure tries to
> output the sample and test binaries at the top level of the
> samples and Tests directories, respectively. For example, the
> samples directory has the following structure:
>
> samples
>
> ApacheModduleXSLT
>
> CompileStylesheet
>
> DocumentBuilder
> EntityResolver
>
> ExternalFunction
>
> …
>
> The Xalan build infrastructure tries to create the sample
> executable in the root of the samples directory. This leads to a
> naming conflict. For example, the build intrastructure tells the
> linker to output the ExternalFunction executable at the root of
> the samples directory. The linker open function fails with the
> error message
>
> [ 93%] Building CXX object
> src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o
>
> cd
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath
> &&
> /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++
> -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport
> -isystem
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include
> -isystem
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include
> -O2 -pipe -pthread
> -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox=
> -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual
> -Wctor-dtor-privacy -Wextra -Wformat=2 -Wmissing-declarations
> -Wno-long-long -Woverlength-strings -Woverloaded-virtual
> -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable
> -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -O2 -pipe
> -pthread
> -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox=
> -fPIC -std=c++11 -std=gnu++14 -o
> CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp
>
> /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
> fatal error: ExternalFunction: open: Is a directory
>
> I noticed that Xerces-c stores the source for its tests and
> samples in a src subdirectory but creates the executables at the
> top of the directory e.g.,
>
> samples
>
> src
>
> CreateDOMDocument
>
> CreateDOMDocument
>
> This avoids the naming conflict.
>
> The Xalan-c samples and tests build without issue on Windows.
>
> Thanks for creating a version of Xalan-c that is easy to build on
> all major platforms.
>
> Regards,
>
> Paul
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
> for Windows 10
>
RE: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Posted by Paul Kinnucan <pa...@mathworks.com>.
Hi Roger,
Thanks for the suggestions.
I tried unsuccessfully to get cmake to use a different build directory. I am new to cmake so I was guessing what I needed to do and my many guesses were wrong.
I am going to try moving the sample and example source directories into src directories below the top directories. This seems to me to require the fewest changes to the cmake build and test scripts for the samples and tests. All I have to do is change the location of the sources in the add_executable commands. The rest of the script should work as is to build and test the executables in the top directories.
I'll let you know how I fare.
Regards,
Paul
From: Roger Leigh <rl...@codelibre.net>
Sent: Saturday, July 25, 2020 4:32 PM
To: dev@xalan.apache.org
Subject: Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Hi Paul,
A quick workaround to try: use a separate build directory then you'll avoid the naming conflicts.
We will absolutely need to fix this. I copied the existing convention but I agree that adopting the Xerces-C++ strategy will be a better solution. See https://issues.apache.org/jira/browse/XALANC-811<https://issues.apache.org/jira/browse/XALANC-811> which I created to track this. An alternative approach would be to deliberately forbid in-source builds and require a separate build directory.
Kind regards,
Roger
On 24/07/2020 22:53, Paul Kinnucan wrote:
Hi,
The Xalan 1.12 samples and tests fail to build on Linux and the Mac. The reason is that the cmake build infrastructure tries to output the sample and test binaries at the top level of the samples and Tests directories, respectively. For example, the samples directory has the following structure:
samples
ApacheModduleXSLT
CompileStylesheet
DocumentBuilder
EntityResolver
ExternalFunction
...
The Xalan build infrastructure tries to create the sample executable in the root of the samples directory. This leads to a naming conflict. For example, the build intrastructure tells the linker to output the ExternalFunction executable at the root of the samples directory. The linker open function fails with the error message
[ 93%] Building CXX object src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o
cd /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath && /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++ -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1 -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include -isystem /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy -Wextra -Wformat=2 -Wmissing-declarations -Wno-long-long -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder -Wswitch-default -Wunused-variable -Wwrite-strings -Wno-variadic-macros -fstrict-aliasing -O2 -pipe -pthread -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox= -fPIC -std=c++11 -std=gnu++14 -o CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp
/mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: fatal error: ExternalFunction: open: Is a directory
I noticed that Xerces-c stores the source for its tests and samples in a src subdirectory but creates the executables at the top of the directory e.g.,
samples
src
CreateDOMDocument
CreateDOMDocument
This avoids the naming conflict.
The Xalan-c samples and tests build without issue on Windows.
Thanks for creating a version of Xalan-c that is easy to build on all major platforms.
Regards,
Paul
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
Re: Xalan 1.12 samples and tests fail to build on Linux and the Mac
Posted by Roger Leigh <rl...@codelibre.net>.
Hi Paul,
A quick workaround to try: use a separate build directory then you'll
avoid the naming conflicts.
We will absolutely need to fix this. I copied the existing convention
but I agree that adopting the Xerces-C++ strategy will be a better
solution. See https://issues.apache.org/jira/browse/XALANC-811 which I
created to track this. An alternative approach would be to deliberately
forbid in-source builds and require a separate build directory.
Kind regards,
Roger
On 24/07/2020 22:53, Paul Kinnucan wrote:
>
> Hi,
>
> The Xalan 1.12 samples and tests fail to build on Linux and the Mac.
> The reason is that the cmake build infrastructure tries to output the
> sample and test binaries at the top level of the samples and Tests
> directories, respectively. For example, the samples directory has the
> following structure:
>
> samples
>
> ApacheModduleXSLT
>
> CompileStylesheet
>
> DocumentBuilder
> EntityResolver
>
> ExternalFunction
>
> …
>
> The Xalan build infrastructure tries to create the sample executable
> in the root of the samples directory. This leads to a naming conflict.
> For example, the build intrastructure tells the linker to output the
> ExternalFunction executable at the root of the samples directory. The
> linker open function fails with the error message
>
> [ 93%] Building CXX object
> src/xalanc/TestXPath/CMakeFiles/TestXPath.dir/TestXPath.cpp.o
>
> cd
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath
> && /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/g++
> -DNDEBUG -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE=1
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/PlatformSupport
> -isystem
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/icu/include
> -isystem
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/install/unknown/glnxa64/xerces-c/include
> -I/mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/NLS/include
> -O2 -pipe -pthread
> -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox=
> -fPIC -std=c++11 -Wall -Wcast-align -Wcast-qual -Wctor-dtor-privacy
> -Wextra -Wformat=2 -Wmissing-declarations -Wno-long-long
> -Woverlength-strings -Woverloaded-virtual -Wredundant-decls -Wreorder
> -Wswitch-default -Wunused-variable -Wwrite-strings
> -Wno-variadic-macros -fstrict-aliasing -O2 -pipe -pthread
> -fdebug-prefix-map=/mathworks/devel/sandbox/paulk/xalan-c-sandbox=
> -fPIC -std=c++11 -std=gnu++14 -o
> CMakeFiles/TestXPath.dir/TestXPath.cpp.o -c
> /mathworks/devel/sandbox/paulk/xalan-c-sandbox/3p/derived/glnxa64/xalan-c/src/xalanc/TestXPath/TestXPath.cpp
>
> /mathworks/hub/3rdparty/internal/5566149/glnxa64/gcc-8.3.0/bin/../lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold:
> fatal error: ExternalFunction: open: Is a directory
>
> I noticed that Xerces-c stores the source for its tests and samples in
> a src subdirectory but creates the executables at the top of the
> directory e.g.,
>
> samples
>
> src
>
> CreateDOMDocument
>
> CreateDOMDocument
>
> This avoids the naming conflict.
>
> The Xalan-c samples and tests build without issue on Windows.
>
> Thanks for creating a version of Xalan-c that is easy to build on all
> major platforms.
>
> Regards,
>
> Paul
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>