tests: blacklist native in C++11

[miri64]

Non-release version of #4038.

[OlegHahm]

@josephnoir, do you know if these tests were supposed to run on native?

[josephnoir]

IIRC they should work fine on native. Did the mutex implementation change?

@gebart, do you recall any problems on native?

[jnohlgard]

@josephnoir I don't have any problems running the tests on native on my machine (g++ (Gentoo 4.9.3 p1.0, pie-0.6.2) 4.9.3)
I guess it could be dependent on toolchain and C++ libraries...

[josephnoir]

On OS X, with clang++, I get the following error:

~/Git/RIOT/sys/cpp11-compat/include/riot/mutex.hpp:47:45: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
  inline constexpr mutex() noexcept : m_mtx{0, PRIORITY_QUEUE_INIT} {}

@gebart, you're right though. The tests run fine on Ubuntu with g++ version 4.9.

[miri64]

My Ubuntu always wants to link to the x86_64 version of libstdc++, though I have the i386 version installed.

$ g++ --version
g++ (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[miri64]

Do I have to install some special package, other then libstdc++6-4.8-dev:i386 and libc6-dev-i386 to have this compile on Ubuntu?

[OlegHahm]

Building works fine, for me but I get a segefault:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0804ae88 in malloc (size=18944) at /home/oleg/git/RIOT/cpu/native/syscalls.c:141
#2  0xf7e8f78b in (anonymous namespace)::pool::pool (this=0xf7f95f00 <(anonymous namespace)::emergency_pool>) at /build/gcc-multilib/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_alloc.cc:117
#3  __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at /build/gcc-multilib/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_alloc.cc:244
#4  _GLOBAL__sub_I_eh_alloc.cc(void) () at /build/gcc-multilib/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_alloc.cc:307
#5  0xf7fe8ec5 in call_init.part () from /lib/ld-linux.so.2
#6  0xf7fe8fee in _dl_init () from /lib/ld-linux.so.2
#7  0xf7fdab8f in _dl_start_user () from /lib/ld-linux.so.2

gcc (GCC) 5.2.0 on Linux 4.1.6-1 (ARCH Linux)

[miri64]

I get

/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.so when searching for -lstdc++
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libstdc++.a when searching for -lstdc++
/usr/bin/ld: cannot find -lstdc++
collect2: error: ld returned 1 exit status
make: *** [all] Error 1
make: Leaving directory `/home/martine/Repositories/RIOT-OS/RIOT/tests/cpp11_condition_variable'

btw.

[OlegHahm]

With clang 3.6.2 I get the same error as @josephnoir.

[josephnoir]

Just tried it on a Ubuntu 15.04 and had to install the packages gcc-multilib and g++-multilib. Where does the -lstdc++come from? I can't find it grepping through the code.

[miri64]

Ha, I hadn't installed those, now with those installed (which pulled in lib32stdc++-4.8-dev, too btw so libstdc++-4.8-dev:i386 was the wrong package for cross-compiling) it's working!

[miri64]

Are those the correct outputs (aka some pexpect scripts would be nice ;-))?

tests/cpp11_condition_variable:

************ C++ condition_variable test ***********
Wait with predicate and notify one ... 
Done

Wait and notify all ...
Done

Wait for ...
Done

Wait until ...
Done

Bye, bye. 
******************************************************

tests/cpp11_mutex:

************ C++ mutex test ***********
Lock and unlock ... 
Done

Try_lock ...
Done

Bye, bye.
*****************************************

tests/cpp11_thread:

************ C++ thread test ***********
Creating one thread and passing an argument ...
Done

Creating detached thread ...
Done

Join on 'finished' thread ...
Done

Join on 'running' thread ...
Done

Testing sleep_for ...
Done

Testing sleep_until ...
Done

Swapping two threads ...
Done

Move constructor ...
Done

Bye, bye.
******************************************

[miri64]

(build on current release branch).

[miri64]

Just tried it on a Ubuntu 15.04 and had to install the packages gcc-multilib and g++-multilib. Where does the -lstdc++ come from? I can't find it grepping through the code.

I guess that's pulled in as soon as you set -std=c++.*.

[josephnoir]

@authmillenon Those are the correct outputs. At the time I thought DONE was speaking enough. The flag thing sound plausible, the standard lib has to be linked at some point ^^

That leaves the segfault with gcc 5.2 and the clang problems ...

[miri64]

(updated the Wikipage, please adapt to your liking if it's not)

[miri64]

I don't have the clang problem:

clang --version
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix

[josephnoir]

Looks like it only exists with newer versions of the compiler, can't find anything on the topic though.

[OlegHahm]

And what about the segfault with gcc?

[miri64]

IMHO we have to come to a decision. Either we document somewhere, that certain compiler versions are not supported for native + C++ for now (and maybe block building them altogether for now) or we fix it.

[OlegHahm]

I agree. Anyone with any clue why it segfaults with newer GCC versions?

[josephnoir]

I can take a look at it tonight.

[OlegHahm]

thx

[OlegHahm]

Just figured that the riot_and_cpp example is segfaulting with my toolchain, too.

[OlegHahm]

gcc-4.9.2 works

[OlegHahm]

For the clang problem, this patch "solves" the problem:

diff --git a/sys/cpp11-compat/include/riot/mutex.hpp b/sys/cpp11-compat/include/riot/mutex.hpp
index d478327..4d10cd9 100644
--- a/sys/cpp11-compat/include/riot/mutex.hpp
+++ b/sys/cpp11-compat/include/riot/mutex.hpp
@@ -44,7 +44,7 @@ class mutex {
  public:
   using native_handle_type = mutex_t*;

-  inline constexpr mutex() noexcept : m_mtx{0, PRIORITY_QUEUE_INIT} {}
+  inline mutex() noexcept : m_mtx{{0}, PRIORITY_QUEUE_INIT} {}
   ~mutex();

   void lock();

[miri64]

Shouldn't it suffice to just set braces around 0 (or use ATOMIC_INIT(0)) and leave the constexpr? (the val member of mutex_t is atomic_int_t since 748499b)

[OlegHahm]

I still get a compiler error if I leave the constexpr.

[josephnoir]

Yeah, found that one too. Problem is, IIRC, the constructor is should be a constexpr.

I have no clue about the gcc thing. The segfault also occurs on Fedora with g++5.1. Seems to occur in syscalls.c, line 141. I don't get any further on my system because I am missing the debug symbols and can't install them for some reason ...

[OlegHahm]

The "gcc thing" is solved with #4043.

[josephnoir]

@OlegHahm Nice.

[miri64]

According to http://en.cppreference.com/w/cpp/language/constexpr is just signifying, that the expression can be evaluated at compile time (and the rules for structs seem to have changed since C++14). If @OlegHahm has a compile error there, it might not be possible to do so, so why not just not make it constexpr?

[miri64]

@OlegHahm are you providing a PR for that before you open a new RC?

[miri64]

(ah, just saw that you already made a new RC).

[josephnoir]

Probably doesn't help if it can't be compiled, although I am wondering why it is working with GCC. Maybe for now, we could leave it constexpr and make a note on the wiki page?

BTW: here is a draft of the standard.

[OlegHahm]

Also not needed any more.

[miri64]

Will someone provide a PR for #4039 (comment) or should I?