My plans to try out openconfigurator on Linux failed twice (for amd64 and x86) because of broken / missing / outdated dependencies. The issue is caused by native libraries dynamically linking to explicit versions of boost libraries.
Even worse, because Fedora 25 does not provide the outdated versions requested by libopenconfigurator_core_lib.so and libopenconfigurator_core_wrapper_java.so (boost 1.54), I would have to compile those versions myself and either copy them to some global library directory (e.g. /usr/lib) which is ugly - or modify LD_LIBRARY_PATH, which requires a lot of effort and can not be expected to be done by ordinary users.
Boost libraries are tiny, linking those libs statically would remove the burden of supplying the requested dependencies from the user.
Br, Clemens
PS: The same is actually true for the windows version. Statically linking the boost dependencies instead of simply shipping all boost-dlls would mean you could get rid of all those unused symbols.
Last edit: Clemens Eisserer 2017-01-24
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
My plans to try out openconfigurator on Linux failed twice (for amd64 and x86) because of broken / missing / outdated dependencies. The issue is caused by native libraries dynamically linking to explicit versions of boost libraries.
Even worse, because Fedora 25 does not provide the outdated versions requested by libopenconfigurator_core_lib.so and libopenconfigurator_core_wrapper_java.so (boost 1.54), I would have to compile those versions myself and either copy them to some global library directory (e.g. /usr/lib) which is ugly - or modify LD_LIBRARY_PATH, which requires a lot of effort and can not be expected to be done by ordinary users.
Boost libraries are tiny, linking those libs statically would remove the burden of supplying the requested dependencies from the user.
Br, Clemens
PS: The same is actually true for the windows version. Statically linking the boost dependencies instead of simply shipping all boost-dlls would mean you could get rid of all those unused symbols.
Last edit: Clemens Eisserer 2017-01-24
Hello Clemens,
Thanks for your feedback!
We'll check your suggestions to statically link the boos libraries to the openCONFIGURATOR lib.
Were you finally able to get it running on your system?
Best regards,
Wolfgang
Unfourtunately I wasn't, when compiling boost 1.54 myself and overwriting the default library search path, it fails with:
/usr/bin/java: symbol lookup error: /home/ce/progs/eclipse-powerlink/plugins/org.epsg.openconfigurator_2.1.1.201610191002/os/linux/x86_64/libopenconfigurator_core_lib.so: undefined symbol: _ZN5boost3log11v2_mt_posix5sinks17text_file_backend9constructERKNS_10filesystem4pathESt13_Ios_OpenmodemRKNS1_3aux14light_functionIFbvEEEb
I guess for now I'll have to use the windows version.