projectchrono
Support for static libraries?
Hi,
Is there some way to compile chronoengine and its modules as static libraries? So far I have manually edited the src/chrono/cmakelists.txt with add_library(ChronoEngineStatic STATIC ${ChronoEngine_FILES})
Is there some support for doing this without manually editing each cmakelists file?
I have successfully built static libs for src/ChronoEngine, src/chrono_irrlicht and src/chrono_postprocess on mac and it is basically just replacing SHARED with STATIC. Currently I am just using sed to perform these changes to the cmakefiles, but it would be very nice if it was supported with a in general.
Yes, we can look into adding optional support for this. Just curious: why do you need/want to use static libraries? Are you having difficulties getting shared libraries to work on MacOS? Also, have you tried this with any other Chrono modules besides the 3 you mention?
Hi @rserban That sounds great! I think https://cmake.org/cmake/help/latest/variable/BUILD_SHARED_LIBS.html could be useful, although I am no cmake expert!
I am interested in having static libraries as I would like to wrap chrono models inside simulation units (FMUs) implementing The Functional Mock-up Interface (FMI). These simulation units are supposed to be standalone, such that they do not require the user to install anything except what is inherent in the given operating system. For this reason, it would be nice to compile everything into a single dylib/so/dll instead of having various shared library dependencies.
I have managed to get shared libraries to work on MacOS using a bunch of install_name_tool commands - but it is really a hassle and it makes the FMUs much more complicated.
I have not tried any other modules than those three, as I do not need them for now. Later, I will need the vehicle module as well. I will be happy to share my current script for static compilation of the modules, I will just have to clean it up a bit. Really, I have just added STATIC instead of SHARED in add_library and then copied the behaviour throughout the files.
Btw. I am working out of a research group at Aarhus University, where we are working with a mechanical PhD Student (Frederik, I believe he has visited you?!).
The build script is here, and in the bottom of the file you can see that I append some lines to the CMakeLists.txt files.
https://github.com/INTO-CPS-Association/chronofmu/blob/ctm/build/thirdparty/make_dependencies.sh
OK, I'll take a look into adding this option when I get a chance (although I'm not completely convinced that the best option is to statically link the Chrono libraries into the FMUs, this may be useful to others as well).
Say hi to Frederik and Ole, --Radu
That sounds great!
I can expand a bit more on why we consider the static linking the better option, in case you are interested.
Will do :)
Hi,
On 11/06/2020 09:29, Casper Thule wrote:
Hi @rserban https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Frserban&data=02%7C01%7Calessandro.tasora%40unipr.it%7C6c354b6ee067448e9d1b08d80dd9321f%7Cbb064bc5b7a841ecbabed7beb3faeb1c%7C0%7C0%7C637274573785981042&sdata=Q2604q%2F0OkVjLL2nL8r%2BihfsHn6iTIMHOQ1dvNgUFBE%3D&reserved=0 I will share my script with you, I just need to clean it up a bit first.
I am interested in having static libraries as I would like to wrap chrono models inside simulation units (FMUs) implementing The Functional Mock-up Interface (FMI). These simulation units are supposed to be standalone, such that they do not require the user to install anything except what is inherent in the given operating system. For this reason, it would be nice to compile everything into a single dylib/so/dll instead of having various shared library dependencies.
I know that the FMU should be self-sufficient, but you are not forced to static link chrono libraries: another option is that you put all the chrono dynamic link libraries inside the FMU. The main FMU dll will refer to them instead automatically instead of searching the system PATH, as they are in the same directory (I mean, this is the Windows policy for searching dll for run time linking).
Alessandro Tasora
I have managed to get shared libraries to work on MacOS using a bunch of install_name_tool commands - but it is really a hassle and it makes the FMUs much more complicated.
I have not tried any other modules than those three, as I do not need them for now. Later, I will need the vehicle module as well. I will be happy to share my current script for static compilation of the modules, I will just have to clean it up a bit. I will post it here later.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fprojectchrono%2Fchrono%2Fissues%2F241%23issuecomment-642466243&data=02%7C01%7Calessandro.tasora%40unipr.it%7C6c354b6ee067448e9d1b08d80dd9321f%7Cbb064bc5b7a841ecbabed7beb3faeb1c%7C0%7C0%7C637274573785981042&sdata=4ut5pp2nBkTa8l2Z9dzqGfPzxeiQqBOG8CL5HkwfIL4%3D&reserved=0, or unsubscribe https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABHTOBBZEGECQVN7XPS2HL3RWCBWBANCNFSM4NZIJCFQ&data=02%7C01%7Calessandro.tasora%40unipr.it%7C6c354b6ee067448e9d1b08d80dd9321f%7Cbb064bc5b7a841ecbabed7beb3faeb1c%7C0%7C0%7C637274573785991030&sdata=Q2Cp3D888uQwwvtOuiyHgE8jf3D%2BhACUH8lFWxEDf24%3D&reserved=0.
Hi @tasora,
I have also succeeded with this using a bunch of install_name_tool commands for mac - some of which could potentially be removed. Though I have not been able to get this to work through cmake.
install_name_tool -change "${CHRONOLIB}/libChronoEngine.dylib" @rpath/libChronoEngine.dylib $SPRINGARTIFACTS/myexe
install_name_tool -change "${CHRONOLIB}/libChronoEngine_irrlicht.dylib" @rpath/libChronoEngine_irrlicht.dylib $SPRINGARTIFACTS/myexe
install_name_tool -change "${CHRONOLIB}/libChronoEngine_postprocess.dylib" @rpath/libChronoEngine_postprocess.dylib $SPRINGARTIFACTS/myexe
install_name_tool -change "${CHRONOLIB}/libChronoEngine.dylib" @rpath/libChronoEngine.dylib $SPRINGARTIFACTS/libChronoEngine_irrlicht.dylib
install_name_tool -change "${CHRONOLIB}/libChronoEngine.dylib" @rpath/libChronoEngine.dylib $SPRINGARTIFACTS/libChronoEngine_postprocess.dylib
install_name_tool -id "libChronoEngine.dylib" $SPRINGARTIFACTS/libChronoEngine.dylib
install_name_tool -id "libChronoEngine_irrlicht.dylib" $SPRINGARTIFACTS/libChronoEngine_irrlicht.dylib
install_name_tool -id "libChronoEngine_postprocess.dylib" $SPRINGARTIFACTS/libChronoEngine_postprocess.dylib
install_name_tool -add_rpath "@executable_path/./" $SPRINGARTIFACTS/myexe
install_name_tool -add_rpath "@rpath/./" $SPRINGARTIFACTS/myexe
install_name_tool -add_rpath "@loader_path/./" $SPRINGARTIFACTS/myexe
My experience is that the search routines are quite different from mac to windows, and windows, in terms of fmus, is just more straightforward. It is also different from Mac to Linux as well. So to create cross-platform FMUs there would be quite some difference between the compilation for the different platforms, whereas with static libraries cmake would take care of it.
If you are interested, there is a build here with both static (staticexe) and dynamic (myexe): https://github.com/INTO-CPS-Association/chronofmu/actions/runs/132063363
I was also thinking that linking statically might give better performance.
Some additions about static chrono libraries:
I tried to build and test the most important modules. I got working:
- core
- postprocess
- OpenGL
- parallel
- Irrlicht If vehicle is added there is a linker problem due to duplicate defined symbols.
- vehicle works, if parallel is not enabled.
As far as I understood, python interpreters cannot load code from static libraries. I tried it yet, but allow to generate *.so modules. In the following configuration chrono_python can be build:
- core
- postprocess
- opengl
- irrlicht
- vehicle
- python In this configuration the *.so files are in principle dylibs or dlls that have been linked to static libraries. That could work, but it doesn't at least on the Mac.
Trying a python example, I get that:
rainerge@Rainers-iMac core % python3 demo_CH_buildsystem.py
Second tutorial: create and populate a physical system
objc[4517]: Class AppDelegate is implemented in both /Volumes/Ramdisk/build-chrono-static/bin/_irrlicht.so (0x10b27d360) and /Volumes/Ramdisk/build-chrono-static/bin/_vehicle.so (0x10d64c470). One of the two will be used. Which one is undefined.
Traceback (most recent call last):
File "demo_CH_buildsystem.py", line 15, in
The good news: demo_PY_parser and demo_PY_import_solidworks work.
I am going to try and build an FMU soon - is the static building somewhere?
I didn't get a chance to look into this yet.
And when I do, it will require some thinking and testing.
If you want to stick with static libraries for your FMUs, I suggest you use your local solution for now.
See https://github.com/projectchrono/chrono/issues/253#issuecomment-669766055 for a script on how to make the dylibs more transferable.