Why is there a copy of tinyxml inside the GET software installation?
I use a CMake script to locate lbtinyxml.so and tinyxml.h. This script depends on finding the library (using the standard linker paths) and then deducing the location of the header file. Until now, on the INDRA/FAZIA acquisition PCs (CentOS7), this worked fine, with the installed system versions
/usr/lib64/libtinyxml.so
/usr/include/tinyxml.h
However, now there is a new addition to LD_LIBRARY_PATH:
/home/acqexp/GET/release-20170928/Linux-x86_64-el7/lib
and this contains libtinyxml.so, which is now the one found by my script, and by deduction
/home/acqexp/GET/release-20170928/Linux-x86_64-el7/include/tinyxml.h
.
Unfortunately, this version of tinyxml.h is unusable:
/home/acqexp/GET/release-20170928/Linux-x86_64-el7/include/tinyxml.h:52:22: fatal error: tinystr.h: No such file or directory
#include "tinystr.h"
(tinystr.h is nowhere to be found on the system, but in fact is not needed as there should be a #define in tinyxml.h which stops it being looked for)
For my CMake script and compilation, no problem: I simply pass an environment variable telling it to look in /usr first of all.
But why bundle a (broken) installation of another package inside the GET software? Surely the configuration step of GET should require that the necessary package(s) be installed on the system?