Wrong include path when using +simCodeTarget=Cpp

[Rüdiger Franke]

Attempting to compile a model with +simCodeTarget=Cpp, the compiler fails as it does not find umfpack.h. This is because an include path in /usr/include/omc/cpp/ModelicaConfig.inc is wrong. It works with the following patch:

ModelicaConfig.inc

@@ -13 +13 @@
 LAPACK_LIBS =  /usr/lib/liblapack.so /usr/lib/libblas.so
 UMFPACK_LIBS =  /home/build/tmp/build/openmodelica-25132/build/lib/omc/libumfpack.a /usr/lib/libblas.so /home/build/tmp/build/openmodelica-25132/build/lib/omc/libamd.a
 
-SUITESPARSE_INCLUDE = /home/build/tmp/build/openmodelica-25132/build/include/omc/c/suitesparse/Include
+SUITESPARSE_INCLUDE = /usr/include/suitesparse
 
 INTEL_TBB_LIBS = 
 INTEL_TBB_INCLUDE = 

The UMFPACK_LIBS paths above appear wrong as well, but this did not harm in my tests.

[Martin Sjölund]

Why do people insist cmake makes everything easier? The cmake parts of OpenModelica behave as they should...

[Marcus Walther]

I think the problem is related to "make install". Have you called something like this?

• make omc
• make runtimeCPPinstall
• make install
• make clean

At the moment we do not take the prefix of "make install" into account. So the absolute paths in "ModelicaConfig.inc" will stay the same and they are always related to the openmodelica - source folder.

[Rüdiger Franke]

I think so ... I just downloaded the readily built nightly for Utopic ... meaning that the bug is in the regular configure scripts.

[Martin Sjölund]

Replying to mwalther:

At the moment we do not take the prefix of "make install" into account. So the absolute paths in "ModelicaConfig.inc" will stay the same and they are always related to the openmodelica - source folder.

That's the wrong way to go. The only path it should consider is the prefix/install path. They are known at configuration time.

[Marcus Walther]

I know that this is the wrong way, I'm working on a fix.

[Rüdiger Franke]

Just checked a fresh install of the released 1.9.2 under Windows. There basically all the paths are wrong (the installation path is c:/OpenModelica1.9.2):

BOOST_LIBS =  c:/OMDev/./lib/3rdParty/boost-1_55/./lib
BOOST_INCLUDE = c:/OMDev/./lib/3rdParty/boost-1_55/.
BOOST_LIBRARIES = 
BOOST_FILESYSTEM_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_filesystem-mgw44-mt-d-1_55.dll
BOOST_SYSTEM_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_system-mgw44-mt-d-1_55.dll
BOOST_SERIALIZATION_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_serialization-mgw44-mt-d-1_55.dll
BOOST_THREAD_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_thread-mgw44-mt-d-1_55.dll
BOOST_PROGRAM_OPTIONS_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_program_options-mgw44-mt-d-1_55.dll
BOOST_LOG_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_log-mgw44-mt-d-1_55.dll
SUNDIALS_LIBS =  c:/OMDev/lib/3rdParty/Sundials/lib/release/mingw/dlls/libsundials_nvecserial.dll c:/OMDev/lib/3rdParty/Sundials/lib/release/mingw/dlls/libsundials_cvodes.dll c:/OMDev/lib/3rdParty/Sundials/lib/release/mingw/dlls/libsundials_idas.dll c:/OMDev/lib/3rdParty/Sundials/lib/release/mingw/dlls/libsundials_kinsol.dll
SUNDIALS_INCLUDE= c:/OMDev/lib/3rdParty/Sundials/include
LAPACK_LIBS =  c:/OMDev//lib/3rdParty/Lapack/Lib/lapack_win32.dll c:/OMDev//lib/3rdParty/Lapack/Lib/blas_win32.dll
UMFPACK_LIBS =  C:/dev/OpenModelica/build/lib/omc/libumfpack.a c:/OMDev/lib/3rdParty/Lapack/Lib/blas_win32.dll C:/dev/OpenModelica/build/lib/omc/libamd.a

SUITESPARSE_INCLUDE = C:/dev/OpenModelica/build/include/omc/c/suitesparse/Include

[Rüdiger Franke]

Here seem to be two two solutions possible: one is the rigorous consideration of install/prefix path. The alternative solution might be more pragmatic: the boost libs are working under Linux. Under Windows the installation of the source code distribution makes them available out-of-the-box as well. The only problems are UMFPACK and SUITESPARSE.

In the case that install/prefix path is a bigger issue, can't then the CMake be modified such that it uses the same lookup rules for UMFPACK_LIBS and SUITESPARSE_INCLUDE as it seems to use for BOOST, i.e. first check the default installation paths and only afterwards the local build directory?

[Marcus Walther]

Yes, checking the system directories in cmake first will help you, at least on linux. But this will not fix the main problem.

All required libs and header-files that are not part of the operating system should be in the build-folder, so that the build folder can be moved to different locations (for example via "make install"). All paths in the "ModelicaConfig.inc" - file should be relative to this build location.
The non-system libraries (like boost on windows) are already part of the build folder, so there is only the need to change the paths in the ModelicaConfig.inc file.

For Example:
BOOST_FILESYSTEM_LIB = c:/OMDev/lib/3rdParty/boost-1_55/lib/libboost_filesystem-mgw44-mt-d-1_55.dll

should be:

BOOST_FILESYSTEM_LIB = $(OMHOME)/bin/libboost_filesystem-mgw44-mt-d-1_55.dll

because the "libboost_filesystem-mgw44-mt-d-1_55.dll" is copied to the build/bin - folder (windows).

Notice that $(OMHOME) is set during model compilation to the build-folder of the omc-executable, that is used to translate the model. So $(OMHOME) is not necessarily the same as the OMHOME Enviroment variable, if you have multiple versions of omc installed.

The non system includes (like the boost includes on windows) are not copied to the build folder, so the bost_include variable will always point to the omdev-folder. Of course this will not work if the release version is used. So we have to copy the boost-header files to the build folder as well. This is an open point at the moment.

This behaviour is similar to all other libary and include - variables that are defined in the ModelicaConfig.inc file.

For Example:
SUITESPARSE_INCLUDE = C:/dev/OpenModelica/build/include/omc/c/suitesparse/Include

should be:

SUITESPARSE_INCLUDE = $(OMHOME)/include/omc/c/suitesparse/Include

As I already said, I'm working on a fix. It is running on linux and windows at the moment. But I need some additional time for testing. I think I can commit my changes on Monday or Tuesday.

[Rüdiger Franke]

Yesterday's changes work with the Linux source code distro and with today's Windows nightly -- Windows just failed to link. Unfortunately there was no Linux nightly available today.

[Marcus Walther]

Oh thanks, the linux nightly build server has only an old version of cmake installed. I've changed the "new" cmake-feature I have used to an older one, so the nightly build should compile now.
Can you please sent me a link to the windows job that fails to link? I cannot see any windows job that is failing on Hudson.

[Martin Sjölund]

Precise has 2.8.7. Wheezy has 2.8.9. The build server has 2.8.10 everywhere it seems:

$ schroot -a -- cmake --version
cmake version 2.8.10.1
cmake version 2.8.10.1
cmake version 2.8.10.1
cmake version 2.8.10.1
cmake version 2.8.10.1
cmake version 2.8.10.1
cmake version 2.8.10.1
cmake version 2.8.10.1
build@build:~$ schroot --list
chroot:precise-amd64
chroot:precise-i386
chroot:trusty-amd64
chroot:trusty-i386
chroot:utopic-amd64
chroot:utopic-i386
chroot:wheezy-amd64
chroot:wheezy-i386

[Rüdiger Franke]

I wanted to wait with the report until the other things have stabilized (like Linux nightly and include/omc/cpp/FMU2 in the distro).

FMI2 export works under Linux (except missing code from Functions.cpp for non-trivial models). The additional linker error under Windows can be reproduced with:

• create the folder C:/OpenModelica1.9.3Nightly/include/omc/cpp/FMU2 with the seven files from the SVN
• rename uint to unsigned int (2x in FMU2Wrapper.h and 1x in FMU2Wrapper.cpp) -- sorry for that; it worked under Linux -- it's too many programming languages that I'm using in parallel :-(
• open OMEdit and add +simCodeTarget=Cpp unter Tools->Options->Simulator->OMC Flags
• browse to a model, like Modelica.Blocks.Continuous.Integrator
• invoke the menu FMI->Export FMU

It gives:

[1] 09:09:01 Scripting Error
translateModelFMU failed

[2] 09:09:01 Translation Error
Error building simulator. Build log: g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_Integrator.o OMCppModelica_Blocks_Continuous_Integrator.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorFMU.o OMCppModelica_Blocks_Continuous_IntegratorFMU.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain2.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain2.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain3.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain3.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain4.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain4.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain5.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain5.cpp g++ -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -c -o OMCppModelica_Blocks_Continuous_IntegratorAlgLoopMain.o OMCppModelica_Blocks_Continuous_IntegratorAlgLoopMain.cpp g++ -shared -I. -o Modelica.Blocks.Continuous.Integrator.dll OMCppModelica_Blocks_Continuous_Integrator.o OMCppModelica_Blocks_Continuous_IntegratorFMU.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain2.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain3.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain4.o OMCppModelica_Blocks_Continuous_IntegratorCalcHelperMain5.o OMCppModelica_Blocks_Continuous_IntegratorAlgLoopMain.o -Winvalid-pch -O0 -DNDEBUG -DBOOST_ALL_DYN_LINK -DOMC_BUILD -DUSE_BOOST_LOG -DUSE_BOOST_THREAD -DPMC_USE_SUNDIALS -DUSE_UMFPACK -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -I"C:/OpenModelica1.9.3Nightly//include/omc/c/suitesparse/Include" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/Core" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp/SimCoreFactory" -I"C:/OpenModelica1.9.3Nightly//include/omc/cpp" -L"C:/OpenModelica1.9.3Nightly//lib/omc/cpp" -L"C:/OpenModelica1.9.3Nightly//bin" -lOMCppSystem_FMU -lOMCppDataExchange_static -lOMCppOMCFactory -lboost_log-mgw44-mt-1_55 -lboost_log-mgw44-mt-d-1_55 -lboost_log_setup-mgw44-mt-1_55 -lboost_log_setup-mgw44-mt-d-1_55 -lboost_thread-mgw44-mt-1_55 -lboost_thread-mgw44-mt-d-1_55 -lboost_atomic-mgw44-mt-1_55 -lboost_atomic-mgw44-mt-d-1_55 -lboost_filesystem-mgw44-mt-1_55 -lboost_filesystem-mgw44-mt-d-1_55 -lboost_system-mgw44-mt-1_55 -lboost_system-mgw44-mt-d-1_55 -lboost_serialization-mgw44-mt-d-1_55 -lboost_program_options-mgw44-mt-1_55 -lboost_program_options-mgw44-mt-d-1_55 OMCppModelica_Blocks_Continuous_IntegratorFMU.o:OMCppModelica_Blocks_Continuous_IntegratorFMU.cpp:(.text+0x15a): undefined reference to `AlgLoopSolverFactory::AlgLoopSolverFactory(IGlobalSettings*, boost::filesystem::path, boost::filesystem::path)' OMCppModelica_Blocks_Continuous_IntegratorFMU.o:OMCppModelica_Blocks_Continuous_IntegratorFMU.cpp:(.text+0x68e): undefined reference to `AlgLoopSolverFactory::AlgLoopSolverFactory(IGlobalSettings*, boost::filesystem::path, boost::filesystem::path)' collect2: ld returned 1 exit status mingw32-make: *** [Modelica.Blocks.Continuous.Integrator.fmu] Error 1 RESULT: 2 

[Rüdiger Franke]

The same linker error shows up if selecting Tools->Options->FMI->1.0, instead of installing and fixing the FMU2 files.

Which runtime lib would provide AlgLoopSolverFactory and the things from Functions.cpp, like division?

[Marcus Walther]

They are part of libOMCppSystem and libOMCppMath. The problem with the FMU-export of the CPP-Runtime is, that nobody is using it and it is just a prototypical implementation, done by a student 1 or 2 years ago.

I think there is a lot of remaining work if you really want to use the FMU export. For example with the boost libraries. They should not be linked dynamically, but statically. Otherwise each system that want to use the FMU has to have the boost libraries in PATH or LD_LIBRARY_PATH.

[Rüdiger Franke]

The FMI part is simple and the previously existing version at least provides a starting point. The interesting question is how the overall Cpp runtime will perform :-)

[Rüdiger Franke]

Under Windows the boost libs seem to work with the nightly r25227. See C:\OpenModelica1.9.3Nightly\include\omc\cpp\ModelicaConfig.inc:

BOOST_LIBS =  $(OMHOME)/bin
BOOST_INCLUDE = $(OMHOME)/include/omc/cpp

Under Linux the BOOST_LIBS path is configured wrong using today's nightly r25243. See /usr/include/omc/ModelicaConfig.inc:

BOOST_LIBS =  .
BOOST_INCLUDE = /usr/include

Could you check this?

Regarding your comment above: Static versions of the boost libs find under Linux just besides the dynamic versions. Under Windows I can't see static versions!?

[Marcus Walther]

Yes, there are no static libraries available at the moment for windows. We have to build them on our own. I can do this, but I have no time this week, so you have to wait until next week.

Regarding the Boost_libs path on linux: The path is system dependent, so if our hudson-build server has boost installed in /opt/boostXYZ, then the released nightly_build will contain BOOST_LIBS=/opt/boostXYZ. Usually the libraries are installed in /usr/lib, so the line should be BOOST_LIBS=/usr/lib, that's really wrong and I'm not sure why he does not find the library path correctly.

Anyway, the target system that runs the nightly build should have boost installed in /usr/lib or any other location that is part of the LD_LIBRARY_PATH environment variable. So the code should run, whatever BOOST_LIBS value is set.
This is because the makefile contains something like this:

g++ ... -L"$(BOOST_LIBS)" -lboost_system ...

If the directory set in $(BOOST_LIBS) is not existing or does not contain any boost-libraries, than the compiler will simply ignore it and search in the default location (LD_LIBRARY_PATH) for the boost_system-library.

Can you confirm that the simulations with the nightly build are compiling/simulating on linux?

[Martin Sjölund]

The path on Ubuntu is: /usr/lib/x86_64-linux-gnu/libboost_system.so

[Marcus Walther]

Thank you Martin,
but this location should be part of the default library search path as well.

[Rüdiger Franke]

Right. In fact the BOOST_LIBS path is not needed. It's the list of BOOST_LIBRARIES itself. The file /usr/include/omc/ModelicaConfig.inc says (after having removed lot of duplications):

BOOST_LIBRARIES =  -lboost_log -lboost_log_setup -lboost_thread -lboost_atomic -lboost_filesystem -lboost_system -lboost_serialization -lboost_program_options

The following boost libs are installed from the regular packages (ls -l /usr/lib/*/*boost*):

-rw-r--r-- 1 root root    5864 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_atomic.so.1.55.0
-rw-r--r-- 1 root root  217700 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_filesystem.a
lrwxrwxrwx 1 root root      29 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so -> libboost_filesystem.so.1.55.0
-rw-r--r-- 1 root root   88936 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.55.0
-rw-r--r-- 1 root root 1824584 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_log_setup.so.1.55.0
-rw-r--r-- 1 root root  803216 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_log.so.1.55.0
-rw-r--r-- 1 root root 1292424 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_program_options.a
lrwxrwxrwx 1 root root      34 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_program_options.so -> libboost_program_options.so.1.55.0
-rw-r--r-- 1 root root  445376 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.55.0
-rw-r--r-- 1 root root 1281790 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_serialization.a
lrwxrwxrwx 1 root root      32 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_serialization.so -> libboost_serialization.so.1.55.0
-rw-r--r-- 1 root root  436976 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_serialization.so.1.55.0
-rw-r--r-- 1 root root   49178 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_system.a
lrwxrwxrwx 1 root root      25 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_system.so -> libboost_system.so.1.55.0
-rw-r--r-- 1 root root   14536 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.55.0
-rw-r--r-- 1 root root   92728 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
-rw-r--r-- 1 root root  870910 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_wserialization.a
lrwxrwxrwx 1 root root      33 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_wserialization.so -> libboost_wserialization.so.1.55.0
-rw-r--r-- 1 root root  318328 Jul 24  2014 /usr/lib/x86_64-linux-gnu/libboost_wserialization.so.1.55.0

It links when reducing the list of boost libraries to the ones that have a symbolic link:

BOOST_LIBRARIES =  -lboost_filesystem -lboost_system -lboost_serialization -lboost_program_options

Should BOOST_LIBRARIES in the file /usr/include/omc/ModelicaConfig.inc be changed accordingly?

Btw.: Now first simulations run from OMEdit with +simCodeTarget=Cpp, including also plotting of results!

[Rüdiger Franke]

The BOOST_LIBS path would be needed for linking the static libs, in order to replace in the makefile something like

-L$(BOOST_LIBS) -lboost-system

with

$(BOOST_LIBS)/libboost-system.a

[Martin Sjölund]

Replying to rfranke:

The BOOST_LIBS path would be needed for linking the static libs

Not true, you can also specify -Wl,-Bstatic -lboost_system -Wl,-Bdynamic (to set a preference for static or dynamic linking if both are available).

[Rüdiger Franke]

Good to know!

Btw. on another Linux system there were many more symbolic links available and the linking worked with the given ModelicaConfig.inc. The difference seems to be that the package libboost-all-dev was installed on that machine, while the other only had libboost-dev. I have no idea where this difference comes from. But everything appears fine with libboost-all-dev.

[Rüdiger Franke]

The ticket (Wrong include path) is solved since about a week.

Regarding the discussion about static linking of boost libs: the static libs contained in the regular Debian package have not been compiled with -fPIC. On the other hand side the dynamic boost libs

• can easily be installed into the regular system dirs
• are considered stable
• make system calls (see also "IT security blocker with static linking" ​https://trac.modelica.org/fmi/ticket/313)

This is why the FMU links the boost libs dynamically.

[Adrian Pop]

We talked a bit about the boost libs in the OSMC dev meeting and at least on Windows in the C runtime we include dependent dlls in the FMU. I guess you can do the same for the FMU CPP runtime so you skip compiling static boost libs.

[Marcus Walther]

I agree to Adrian, at least on Windows we should deliver the DLLs as part of the FMU, if you don't want to link statically.

Just because you talked about security reasons:
If you link dynamically against a dll, than it's more easy to manipulate the behaviour of your code be delivering an infected dll to your system...an anti-virus software will not help you in this case. And as already seen with the stuxnet attack, even nuclear power plants are not save from viruses delivered in dlls.