Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#5948 closed defect (fixed)

Cpp runtime fails to link a model under Ubuntu 20.04 LTS (Focal Fossa)

Reported by: Rüdiger Franke Owned by: Andreas Heuermann
Priority: blocker Milestone: 1.14.2
Component: Build Environment Version:
Keywords: Cc: Niklas Worschech

Description

Compiled OpenModelica according to docu:

echo deb http://build.openmodelica.org/apt bionic nightly | sudo tee -a /etc/apt/sources.list
echo deb-src http://build.openmodelica.org/apt bionic nightly | sudo tee -a /etc/apt/sources.list
sudo apt-get update
sudo apt-get build-dep openmodelica
git clone --recursive https://openmodelica.org/git-readonly/OpenModelica.git OpenModelica
cd OpenModelica
autoconf
./configure --with-cppruntime
make -j16

Afterwards attempted to simulate the MSL ThreeTanks example in OMEdit using the Cpp runtime. This gives:

make -j16 -f Modelica.Fluid.Examples.Tanks.ThreeTanks.makefile
g++ -fopenmp  -Winvalid-pch -O0 -g -DNDEBUG -fPIC   -std=c++11 -DBOOST_ALL_DYN_LINK   -DUSE_DGESV -DUSE_LOGGER -DOMC_BUILD -DUSE_PUGI_XML -DUSE_THREAD -DSUNDIALS_MAJOR_VERSION=2 -DSUNDIALS_MINOR_VERSION=6 -DPMC_USE_SUNDIALS -I"." -I"/home/franke/OpenModelica/build/bin/../include/omc/cpp/" -I.  -I"." -I"." -I"/home/franke/OpenModelica/build/include/omc/c/sundials"     -DMEASURETIME_PROFILEBLOCKS -DUSE_LOGGER  -c -o OMCppModelica.Fluid.Examples.Tanks.ThreeTanksCalcHelperMain.o OMCppModelica.Fluid.Examples.Tanks.ThreeTanksCalcHelperMain.cpp
g++ -fopenmp -shared -o OMCppModelica.Fluid.Examples.Tanks.ThreeTanks.so OMCppModelica.Fluid.Examples.Tanks.ThreeTanksCalcHelperMain.o -L"/home/franke/OpenModelica/build/lib/omlibrary/Modelica 3.2.3/Fluid/Examples"   -lOMCppSystem -lOMCppModelicaUtilities -lOMCppDataExchange -lOMCppMath -lOMCppExtensionUtilities -lOMCppOMCFactory -L"/home/franke/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/cpp"    -Wl,-rpath,"/home/franke/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/cpp"  -L"." -lBoost::filesystem -lBoost::system -lBoost::serialization -lBoost::program_options -ldl -L/usr/lib/x86_64-linux-gnu -llapack -lblas 
/usr/bin/ld: cannot find -lBoost::filesystem
/usr/bin/ld: cannot find -lBoost::system
/usr/bin/ld: cannot find -lBoost::serialization
/usr/bin/ld: cannot find -lBoost::program_options
collect2: error: ld returned 1 exit status
make: *** [Modelica.Fluid.Examples.Tanks.ThreeTanks.makefile:77: Modelica.Fluid.Examples.Tanks.ThreeTanks] Error 1
Compilation process failed. Exited with code 2.

The linker flags appear wrong. I think that same happens for the maintentance/v1.15 branch.
Debian Jessie uses different linker flags, like -lboost_filesystem.

Change History (18)

comment:1 by Adrian Pop, 5 years ago

Might be because you don't have boost installed?
As far as I know: sudo apt-get build-dep openmodelica doesn't install boost, that one is optional (if you configure with --with-cppruntime).

comment:2 by Rüdiger Franke, 5 years ago

No. It somehow installed libboost-all-dev

comment:3 by Martin Sjölund, 5 years ago

/usr/include/omc/omsicpp/ModelicaConfig_gcc.inc:BOOST_LIBRARIES= -lboost_filesystem -lboost_system -lboost_serialization -lboost_program_options
/usr/include/omc/omsicpp/ModelicaConfig_gcc.inc:BOOST_FILESYSTEM_LIB=boost_filesystem

That's generated on my system. I guess this is a cmake issue since I believe that's what is generating that file...

comment:4 by Rüdiger Franke, 5 years ago

Indeed. Cmake configures wrong boost libs in my ModelicaConfig_gcc.inc. It is strange that the Cpp runtime compiles, i.e. cmake configures correct boost libs at other places !?

comment:5 by Rüdiger Franke, 5 years ago

@sjoelund.se: "That's generated on my system." What kind of system do you run?

In order to confirm, I installed a fresh Ubuntu 20.04 desktop as follows:

  • select minimal installation (without office, games, codecs, etc.)
  • installed VirtualBox extension and vscode
  • executed the documented commands to clone and build OpenModelica (see above) using focal instead of bionic
  • needed to add [trusted=yes] to the OpenModelica entries in /etc/apt/sources.list to turn an error for missing signature to a warning !?
  • additionally installed git and flex -- should be added to build-dep openmodelica

The result is the same as in my grown Ubuntu 20.04 machine.

comment:6 by Rüdiger Franke, 5 years ago

Cc: Niklas Worschech added

comment:7 by Rüdiger Franke, 5 years ago

CMake intentionally uses double colons "to namespace IMPORTED targets and ALIAS targets". Something changed in newer versions:

https://cmake.org/cmake/help/v3.0/policy/CMP0028.html

Somehow a misuse of cmake or its policies if the libs are correct for the actual compilation of the Cpp runtime, but are written wrong to ModelicaConfig_gcc.inc.

If OpenModelica doesn't compile under the LTS release of Ubuntu anymore (and neither under the latest Debian, see #5950), then this should effect many other Linux distros as well.

comment:8 by Andreas Heuermann, 5 years ago

I tried WSL with Ubuntu 20.04 TLS (I went along README-Windows-WSL.md but replaced bionic with focal) and could reproduce the issue.

me@MY_PC:~/workspace/OpenModelica/testsuite/openmodelica/cppruntime/libraries/msl32$ omc Modelica.Fluid.Examples.Tanks.ThreeTanks.mos
true
true
""
record SimulationResult
    resultFile = "",
    simulationOptions = "startTime = 0.0, stopTime = 200.0, numberOfIntervals = 500, tolerance = 1e-06, method = 'dassl', fileNamePrefix = 'Modelica.Fluid.Examples.Tanks.ThreeTanks', options = '', outputFormat = 'mat', variableFilter = '.*', cflags = '', simflags = ''",
    messages = "Failed to build model: Modelica.Fluid.Examples.Tanks.ThreeTanks",
    timeFrontend = 1.6432559,
    timeBackend = 0.2577561,
    timeSimCode = 0.0225103,
    timeTemplates = 0.0513228,
    timeCompile = 3.1041964,
    timeSimulation = 0.0,
    timeTotal = 5.0791015
end SimulationResult;
"Error: Error building simulator. Build log: clang++ -fopenmp=libomp  -Winvalid-pch -O0 -g -DNDEBUG -fPIC   -std=c++11 -DBOOST_ALL_DYN_LINK   -DUSE_DGESV -DUSE_LOGGER -DOMC_BUILD -DUSE_THREAD -DSUNDIALS_MAJOR_VERSION=2 -DSUNDIALS_MINOR_VERSION=6 -DPMC_USE_SUNDIALS -DENABLE_OMSI -I"."  -I"/home/andreas/workspace/OpenModelica/build/bin/../include/omc/omsi/" -I"/home/andreas/workspace/OpenModelica/build/bin/../include/omc/omsi/base" -I"/home/andreas/workspace/OpenModelica/build/bin/../include/omc/omsi/solver" -I"/home/andreas/workspace/OpenModelica/build/bin/../include/omc/omsicpp/" -I.  -I"." -I"." -I"/home/andreas/workspace/OpenModelica/build/include/omc/c/sundials"     -DMEASURETIME_PROFILEBLOCKS -DUSE_LOGGER  -c -o OMCppModelica.Fluid.Examples.Tanks.ThreeTanksCalcHelperMain.o OMCppModelica.Fluid.Examples.Tanks.ThreeTanksCalcHelperMain.cpp
clang++ -fopenmp=libomp -shared -o OMCppModelica.Fluid.Examples.Tanks.ThreeTanks.so OMCppModelica.Fluid.Examples.Tanks.ThreeTanksCalcHelperMain.o -L"/home/andreas/workspace/OpenModelica/build/lib/omlibrary/Modelica 3.2.1/Fluid/Examples"   -lOMCppSystemBase -lOMCppExtendedSystem -lOMCppModelicaUtilities -lOMCppDataExchange -lOMCppMath -lOMCppExtensionUtilities -lOMCppOMCFactory -L"/home/andreas/workspace/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/omsicpp"    -Wl,-rpath,"/home/andreas/workspace/OpenModelica/build/bin/../lib/x86_64-linux-gnu/omc/omsicpp"  -L"/usr/lib/x86_64-linux-gnu" -lBoost::filesystem -lBoost::system -lBoost::serialization -lBoost::program_options -ldl -L/usr/lib/x86_64-linux-gnu -llapack -lblas
/usr/bin/ld: cannot find -lBoost::filesystem
/usr/bin/ld: cannot find -lBoost::system
/usr/bin/ld: cannot find -lBoost::serialization
/usr/bin/ld: cannot find -lBoost::program_options
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [Modelica.Fluid.Examples.Tanks.ThreeTanks.makefile:78: Modelica.Fluid.Examples.Tanks.ThreeTanks] Error 1
"
{"Error opening file: /home/andreas/workspace/OpenModelica/testsuite/openmodelica/cppruntime/libraries/msl32/Modelica.Fluid.Examples.Tanks.ThreeTanks_res.mat"}

Problem is wrong library names for boost in ModelicaConfig_gcc.inc:

BOOST_LIBS=/usr/lib/x86_64-linux-gnu
BOOST_INCLUDE=.
BOOST_LIBRARIES= -lBoost::filesystem -lBoost::system -lBoost::serialization -lBoost::program_options


BOOST_SYSTEM_LIB=
BOOST_FILESYSTEM_LIB=
BOOST_PROGRAM_OPTIONS_LIB=

I don't get it to simulate when I change the BOOST_LIBRARIES though

BOOST_LIBS=/usr/lib/x86_64-linux-gnu
BOOST_INCLUDE=.
BOOST_LIBRARIES= -lboost_filesystem -lboost_system -lboost_serialization -lboost_program_options

BOOST_SYSTEM_LIB=boost_system
BOOST_FILESYSTEM_LIB=boost_filesystem
BOOST_PROGRAM_OPTIONS_LIB=boost_program_options

With this (and after building testsuite-depends) I get the test to run.

Last edited 5 years ago by Andreas Heuermann (previous) (diff)

comment:9 by Andreas Heuermann, 5 years ago

I blame CMake for this:

CMake version on 18.04 TLS: cmake version 3.10.2
CMake version on 20.04 TLS: cmake version 3.16.3

My guess is that the behavior of FindBoost has changed and we need to do something similar to
Commit 598c381

comment:10 by Adrian Pop, 5 years ago

I could also reproduce it with a built from scratch omc.

comment:11 by Andreas Heuermann, 5 years ago

See https://github.com/OpenModelica/OpenModelica/pull/881 for an ugly fix.

But there has to be a nice way to do this.
Any CMake-Ninjas here?

Last edited 5 years ago by Andreas Heuermann (previous) (diff)

comment:12 by Adrian Pop, 5 years ago

CMake has changed the way find_package(Boost) works:

find_package(Boost 1.41.0 COMPONENTS filesystem system ${LIB_BOOST_REGEX} ${LIB_BOOST_ATOMIC} REQUIRED)
  IF(Boost_FOUND)
    message(STATUS "Found Boost")
    message(STATUS "  Boost_LIBRARIES:    " ${Boost_LIBRARIES})
    message(STATUS "  Boost_LIBRARY_DIRS: " ${Boost_LIBRARY_DIRS})
    message(STATUS "  Boost_INCLUDE_DIRS: " ${Boost_INCLUDE_DIRS})
  ENDIF()

After running this, you now get:

-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.41.0") found components: filesystem system
-- Found Boost
--   Boost_LIBRARIES:    Boost::filesystem Boost::system
--   Boost_LIBRARY_DIRS: /usr/lib/x86_64-linux-gnu
--   Boost_INCLUDE_DIRS: /usr/include

So those Boost::libName are actually on purpose and when they are given to target_link_library they will be replaced and work just fine, but of course when they are given as libraries to the linker as it is the case with ModelicaConfig_gcc.inc it will break.

We just need a way to go from Boost::LibraryName to -lLibraryName and CMake for sure has this functionality, now is just a matter of actually finding it. I'll have a look on how target_link_library replaces these weird defined names to actual libs.

comment:13 by Adrian Pop, 5 years ago

This will search for each of the boost libraries for the location:

    foreach (prop ${Boost_LIBRARIES}) 
      get_target_property(lib ${prop} LOCATION)
      message(STATUS "The name ${prop} has location: ${lib}.")
    endforeach(prop)
-- Found Boost
--   Boost_LIBRARIES:    Boost::filesystemBoost::system
--   Boost_LIBRARY_DIRS: /usr/lib/x86_64-linux-gnu
--   Boost_INCLUDE_DIRS: /usr/include
-- The name Boost::filesystem has location: /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.71.0.
-- The name Boost::system has location: /usr/lib/x86_64-linux-gnu/libboost_system.so.1.71.0.

comment:14 by Adrian Pop, 5 years ago

Previous cmake gives this:

-- Boost version: 1.58.0
-- Found the following Boost libraries:
--   filesystem
--   system
-- Found Boost
--   Boost_LIBRARIES:    /usr/lib/x86_64-linux-gnu/libboost_filesystem.so/usr/lib/x86_64-linux-gnu/libboost_system.so
--   Boost_LIBRARY_DIRS: /usr/lib/x86_64-linux-gnu
--   Boost_INCLUDE_DIRS: /usr/include

So I guess we could manage to fix this using get_target_property.

comment:15 by Andreas Heuermann, 5 years ago

Component: Cpp Run-timeBuild Environment
Owner: changed from somebody to Andreas Heuermann
Status: newassigned

comment:16 by Adrian Pop, 5 years ago

Resolution: fixed
Status: assignedclosed

comment:17 by Francesco Casella, 4 years ago

Milestone: 1.15.01.16.0

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

comment:18 by Francesco Casella, 4 years ago

Milestone: 1.16.01.14.2
Note: See TracTickets for help on using tickets.