search

preshing / cpp11-on-multicore

Various synchronization primitives for multithreaded applications in C++11.
zlib License
517 stars 102 forks source link

Tests fails to build on clang 3.5/6/7 on Ubuntu #2

Closed mintyc closed 9 years ago

mintyc commented 9 years ago

On ubuntu 14.04-2 LTS OK with gcc 4.8.2 - links and runs Changing to clang++-3.5 /3.6 or recent 3.7 fails link due to a change in source in benaphore.h based on __llvm__ (gcc not supporting atomic_init)

recursivebenaphoretester.cpp.o: In function 'testRecursiveBenaphore()': undefined reference to void std::atomic_init<std::thread_id>(std::atomic<std::thread::id>*,std::thread::id)

Having clang use gcc's path through constructor by commenting out ifdefs etc - now compiles OK and runs - downside - probably on OSX/clang?

Not sure what fix to propose? I see you have different problems with clang on OSX which caused this problem in the first place. Maybe instead of __llvm__ combine with some OSX only define to tweak the logic? (Also looks like atomic_init() only got implemented in gcc's libstdc++ in Jan 2015 so will take a while to propagate)

preshing commented 9 years ago

I ran some experiments using the latest Clang 3.7 (built from sources) on Debian. I was able to reproduce your link error when compiling with libstdc++. When compiling with libc++ (by specifying -stdlib=libc++ in BuildSettings.cmake), the error goes away. In fact, either method of initializing m_owner works with libc++ on Debian.

I haven't gone back to check Apple LLVM 6.0 yet, but I'm pretty sure it's also using libc++. That raises the question of why Apple LLVM 6.0 doesn't like to initialize m_owner via the constructor. I don't know if it's because it's using an older version of libc++, or because there's something peculiar about the implementation of std::thread::id on MacOS X.

For now, I'll work around the problem as you suggested: prefer atomic_init only when (defined(__llvm__) && defined(__APPLE__).