C++ runtime broken using boost_thread 1.55 under Ubuntu with clang

[Martin Sjölund]

C++ runtime seems to be broken using boost 1.55 (only boost available in Ubuntu 15.04; Ubuntu 14.04 has 1.54 and 1.55 to choose from, which is why hudson works for now).

GDB reports (using -g -O0):

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff73258d0 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>() ()
   from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
(gdb) bt
#0  0x00007ffff73258d0 in boost::exception_ptr boost::exception_detail::get_static_exception_object<boost::exception_detail::bad_exception_>() ()
   from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#1  0x00007ffff7320141 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.55.0
#2  0x00007ffff7de95ba in call_init (l=<optimised out>, argc=argc@entry=21, 
    argv=argv@entry=0x7fffffffe2b8, env=env@entry=0x7fffffffe368)
    at dl-init.c:72
#3  0x00007ffff7de96cb in call_init (env=<optimised out>, 
    argv=<optimised out>, argc=<optimised out>, l=<optimised out>)
    at dl-init.c:30
#4  _dl_init (main_map=0x7ffff7ffe188, argc=21, argv=0x7fffffffe2b8, 
    env=0x7fffffffe368) at dl-init.c:120
#5  0x00007ffff7dd9d0a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#6..28  in ?? ()

[Niklas Worschech]

we are using boost 1.55 on windows and we don't have this problem. Do you have a model, that generates this error?

[Martin Sjölund]

Every single model triggers the error (it is at the start of the process, so some initializer).

[Rüdiger Franke]

Let's clarify what's going on. I installed a fresh Lubuntu 15.04. Then the packages

• openmodelica
• omlib-modelicaservices-3.2.1
• omlib-complex-3.2.1
• libomccpp

The latter installed a couple of boost libs in version 1.55. That's sufficient to export FMUs and run them.

Attempting to generate a simulation executable with the Cpp runtime, I get linker errors:

/usr/bin/ld: cannot find -lboost_log
/usr/bin/ld: cannot find -lboost_log_setup
/usr/bin/ld: cannot find -lboost_log
/usr/bin/ld: cannot find -lboost_log_setup
/usr/bin/ld: cannot find -lboost_thread
/usr/bin/ld: cannot find -lboost_atomic
/usr/bin/ld: cannot find -lboost_log
/usr/bin/ld: cannot find -lboost_log_setup
/usr/bin/ld: cannot find -lboost_thread
/usr/bin/ld: cannot find -lboost_atomic

What is the intention of the metapackage libomccpp? Shall it just install the runtime libs (and enable the export of FMUs) or shall it enable the generation of simulators as well? If I recall right from my previous use of Lubuntu 14.10, one needs to install the *boost-*dev packages to generate simulators.

For the sake of simplicity, I installed libboost-all-dev on the fresh Lubuntu 15.04. Then I can build the simulator for e.g. Modelica.Blocks.Examples.PID_Controller. It crashes as described in the ticket.

It works when building the simulator with gcc and g++, i.e. the default compilers of the system, instead of clang and clang++. Would it be possible to just use default versions of boost and the default system compiler for the Cpp runtime -- and to get libboost-all-dev installed from the beginning?

[Martin Sjölund]

My system default compiler is clang. I use Ubuntu 15.04:

$ cc --version
Ubuntu clang version 3.6.0-2ubuntu1 (tags/RELEASE_360/final) (based on LLVM 3.6.0)
Target: x86_64-pc-linux-gnu
Thread model: posix

I don't know why you need to link in the boost libraries again. Linking to the cpp runtime shared object will pull in these objects as well.

[Rüdiger Franke]

I did not mean Your default system compiler, but the compiler used by the developers of packages like boost.

[Rüdiger Franke]

The crash appears to happen with static constructors before the main function is entered. A functioning simulation executable can be generated under Ubuntu with clang when removing -DUSE_BOOST_THREAD from the file /usr/include/omc/cpp/ModelicaConfig_gcc.inc.

Other's have already been encountering the problem. See e.g. ​http://stackoverflow.com/questions/29855460/how-to-use-boost-threads-with-clang

Again, why not using gcc under Linux and leaving clang for the OSX users?

[Martin Sjölund]

Well. clang was used by default since its compilation performance was vastly superior to gcc on OpenModelica-generated code while generating faster executables. It has worked really well so far.

We have used clang on OpenModelica since before it was the default on OSX.

[Martin Sjölund]

Simply adding -std=c++11 seems to work (I guess boost uses workarounds in that case). Seems like a better fix anyway.

[Rüdiger Franke]

As for the C++ runtime, clang appears to generate slower code than gcc. Also I find it a pity when attempting to keep virtual machines as small as possible and then the openmodelica package installs all the clang stuff, in a addition to the already existing gcc.

Nevertheless your proposal sounds good to me. Boost generally appears to be a kind of experimental version of the forthcoming C++ standard. Things like thread or array have basically been taken over from boost to C++11. Also I was missing C++11 here and then, e.g. for initializers or lambda expressions. So why not enabling C++11 and getting rid of some boost dependencies? Would this possibly conflict with some older systems that shall still be supported?

[Martin Sjölund]

g++-4.4 on MinGW32 has pretty bad C++11 support.

[Marcus Walther]

Replacing the boost stuff with C++11 features would be great, but the compilers for the Bosch Rexroth controllers do not support C++11 and therefore it is not an option at the moment.

[Martin Sjölund]

Just enabling C++11 in the compiler makes boost change its internal implementation to use C++11 in some places. Which in for example the threading case above seems to help.

[Rüdiger Franke]

But this would also remove error messages if other C++ 11 features are used in the code. These error messages are important to not break compatibility with the target platforms.

[Rüdiger Franke]

You say "clang was used by default since its compilation performance was vastly superior to gcc". The nightly tests use gcc 4.4. Both, gcc and clang are under heavy development. Do you have an up-to-date comparison?

Would it be a compromise to just compile OpenModelica with clang if this has advantages, but to ship the runtime with the system compiler per default, i.e. gcc under Linux? Clang might be available as optional package for the runtime.

The system compiler reduces the footprint of OpenModelica, reduces possible conflicts with other libraries, and, in the case of C++, also improves the performance.

[Martin Sjölund]

Hudson says the test suite performance is:
GCC 4.6: 9m37s
GCC 4.8: 9m27s (Ubuntu 14.04 default)
GCC 4.9: 7m26s
clang: 7m5s (100% success; gcc does not quite manage that)

[Rüdiger Franke]

Thank you for the timings! Ubuntu 14.10 and 15.04 come with gcc 4.9 per default, which doesn't look so bad.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Marcus Walther]

I have added a better support for c++11 to the cpp-runtime. CMake will check if c++11 is available and will add the "-std=c++11" flag if necessary (for OSX: "-std=c++11 -stdlib=libc++"). To proceed this check, a compiler must accept the "-std=c++11" flag. Limited support via "-std=c++0x" is not enough. Thus, GCC 4.4 will build with c++03. The c++11 support of the c++ runtime can be fully disabled with autoconf / cmake if required.

Some boost types (e.g. boost::shared_ptr, boost::weak_ptr, boost::thread ...) are replaced by their c++11 equivalents, if c++11 was detected.

This commit has fixed the issue with boost_thread 1.55 on my virtual machine and I hope that I can fix the Mac OS Cpp-Test with my changes as well.

[Marcus Walther]

@sjoelund.se: Can you change the Hudson-Job "OpenModelica_BUILD_GCC_5" to use GCC 5 for the C and C++ runtime? Than I can check if the issue is fixed on Hudson as well.

[Martin Sjölund]

I will try; it might work if no boost functions taking strings are used.

[Marcus Walther]

Thank you Martin, now it seems to be an issue with the boost program_options library.

[Martin Sjölund]

I'm putting it back to g++-4.9 for now. It should work better on more modern systems now regardless.

[Marcus Walther]

Thanks Martin, I thought that the GCC 5 issue is related to the clang issue that was reported in this ticket...but the GCC 5 problem seems to be related to an ABI change in GCC 5.

"The libstdc++ that comes with gcc 5 had to make some changes to std::string and std::list for conformance with C++11. For backwards compatibility it supports a dual ABI, but it uses the new ABI by default."

I will try to use the backward compatibility mode.

[Marcus Walther]

It seems to work with GCC 5 after my changes (6f376720754bf278dfae4c73c9ebf17129eeba31).
@sjoelund.se: It would be nice if you can test the Hudson job again (hopefully this is the last time you have to change the job-configuration) -- if it's working, we can close the ticket.

[Martin Sjölund]

Nice, the GCC5 job seems to have passed.

[Marcus Walther]

@sjoelund.se: Have you found some remaining issues with the build or can I close the ticket?

[Martin Sjölund]

Well, Ubuntu 15.10 still doesn't compile using clang. But that's because they are shipping an older clang version that does not understand g++-5.x include-files. It does, however, break the nightly builds for 15.10...

[Rüdiger Franke]

Please consider using the system compiler, i.e. gcc under Linux. The use of clang makes pre-built binaries rather useless for us. We have to compile everything ourselves instead.

[Martin Sjölund]

What makes them useless? clang++ uses the exact same c++ library as g++.

[Marcus Walther]

The g++ libraries are not 100% compatible to clang++ after the ABI change in GCC 5.x -- so now it depends how the pre-built libraries were build. In my opinion, if you want to be on the safe side you have to rebuild all dependent libraries with clang++.
However, can you please post the link to the hudson job that builds with clang and Ubuntu 15.10? I could not find it.

[Martin Sjölund]

The latest clang handles the newer ABI.

[Martin Sjölund]

15.10 failed build (using older clang)

[Rüdiger Franke]

The +std=c++11 setting was basically the right solution for this, because then the C++ system libraries take care -- and they work. The ABI tweaks further improve the situation. It does not make sense to invest more time into old compilers running on new systems and not supporting them approprately.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed