Xdmf issueshttps://gitlab.kitware.com/crayzeewulf/xdmf/-/issues2017-09-30T17:40:45-04:00https://gitlab.kitware.com/crayzeewulf/xdmf/-/issues/4Problematic using-declarations in Xdmf3 header(s)...2017-09-30T17:40:45-04:00CrayzeeWulfProblematic using-declarations in Xdmf3 header(s)...Xmdf3 header file `core/XdmfSharedPtr.hpp` contains the following [using declaration](http://en.cppreference.com/w/cpp/language/using_declaration):
```c++
using boost::shared_ptr;
```
This promotes `shared_ptr` to global namespac...Xmdf3 header file `core/XdmfSharedPtr.hpp` contains the following [using declaration](http://en.cppreference.com/w/cpp/language/using_declaration):
```c++
using boost::shared_ptr;
```
This promotes `shared_ptr` to global namespace when this header is included directly or indirectly. This may cause conflicts with `std::shared_ptr`. Placing using-declarations in library header files should be discouraged especially in global namespace. A slightly better alternative would be to put this in a library-specific namespace. For example:
```c++
namespace Xdmf
{
using boost::shared_ptr;
}
```
The safest option is to put this using-declaration in the innermost block that needs it in `.cpp` files. Alternatively, it may be placed at the top of the `.cpp`file that need it (or in a header that is for internal use only and is never installed as part of the library). https://gitlab.kitware.com/crayzeewulf/xdmf/-/issues/3Xdmf3 pollutes global namespace2017-09-30T17:40:45-04:00CrayzeeWulfXdmf3 pollutes global namespaceAll classes/functions provided by Xdmf3 are in global namespace (C++). This pollutes the global namespace. They ought to be placed in a library-specific namespace such as `Xdmf`. All classes/functions provided by Xdmf3 are in global namespace (C++). This pollutes the global namespace. They ought to be placed in a library-specific namespace such as `Xdmf`. https://gitlab.kitware.com/crayzeewulf/xdmf/-/issues/2Invalid XPointer in XDMF output if `XdmfDomain::accept()` is called more than...2017-09-30T17:40:45-04:00CrayzeeWulfInvalid XPointer in XDMF output if `XdmfDomain::accept()` is called more than once...If `XdmfDomain::accept()` is called more than once on the same `XdmfDomain` object then the XPointers in the resulting `.xmf` file are invalid.
For example, if the last line of the example file `XdmfExampleWrite.py`:
```python
...If `XdmfDomain::accept()` is called more than once on the same `XdmfDomain` object then the XPointers in the resulting `.xmf` file are invalid.
For example, if the last line of the example file `XdmfExampleWrite.py`:
```python
primaryDomain.accept(exampleWriter)
```
is replaced with two calls to `accept()`:
```python
primaryDomain.accept(exampleWriter)
primaryDomain.accept(exampleWriter)
```
then the resulting `.xmf` file is corrupted and contains invalid XPointers. CrayzeeWulfCrayzeeWulfhttps://gitlab.kitware.com/crayzeewulf/xdmf/-/issues/1Error while linking `_XdmfCore.so` without selecting to build shared library...2017-09-30T17:40:45-04:00CrayzeeWulfError while linking `_XdmfCore.so` without selecting to build shared library...If `BUILD_SHARED_LIBS` is not set while configuring a build then linking `_XdmfCore.so` fails with the following error message:
```output
[ 98%] Linking CXX shared module ../_XdmfCore.so
/bin/ld: libXdmfCore.a(XdmfArray.cpp.o): relo...If `BUILD_SHARED_LIBS` is not set while configuring a build then linking `_XdmfCore.so` fails with the following error message:
```output
[ 98%] Linking CXX shared module ../_XdmfCore.so
/bin/ld: libXdmfCore.a(XdmfArray.cpp.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
libXdmfCore.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
core/CMakeFiles/_XdmfCorePython.dir/build.make:106: recipe for target '_XdmfCore.so' failed
make[2]: *** [_XdmfCore.so] Error 1
CMakeFiles/Makefile2:199: recipe for target 'core/CMakeFiles/_XdmfCorePython.dir/all' failed
make[1]: *** [core/CMakeFiles/_XdmfCorePython.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
[100%] Linking CXX shared module _Xdmf.so
/bin/ld: libXdmf.a(XdmfAttribute.cpp.o): relocation R_X86_64_32 against `_ZTV13XdmfAttribute' can not be used when making a shared object; recompile with -fPIC
libXdmf.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
CMakeFiles/_XdmfPython.dir/build.make:107: recipe for target '_Xdmf.so' failed
make[2]: *** [_Xdmf.so] Error 1
CMakeFiles/Makefile2:105: recipe for target 'CMakeFiles/_XdmfPython.dir/all' failed
make[1]: *** [CMakeFiles/_XdmfPython.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
```
For example, the above error can be reproduced by using the following commands to configure and build XDMF:
```sh
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=${XDMF_INSTALL_DIR} \
-DBUILD_SHARED_LIBS=0 -DXDMF_WRAP_PYTHON=1 -Wno-dev
make
```
As seen from the error message, the build tries to link a shared object file using `libXdmfCore.a` which results in an error. This error goes away if `BUILD_SHARED_LIBS` is set. The build scripts should either automatically build the shared library if it is essential or display a clearer error message to the user asking them to enable building the shared library.