I get this stacktrace using a program compiled with gcc 5.4.0 from ports. It is gcc5-5.4.0_3 GNU Compiler Collection 5 but previous package versions of 5.4 had the same issue. I cannot try out how 6.4 fares, because it fails to compile gnustep stuff for me. #0 0x00000000 in ?? () #1 0x29c0ad42 in __cxxabiv1::__dynamic_cast (src_ptr=0x2e904a80, src_type=0x2973c618 <typeinfo for icu::UObject>, dst_type=0x2973d8b8 <typeinfo for icu::UnicodeString>, src2dst=0) at /usr/ports/lang/gcc5/work/gcc-5.4.0/libstdc++-v3/libsupc++/dyncast.cc:72 #2 0x2942d51d in icu::Calendar::makeInstance(icu::Locale const&, UErrorCode&) () from /usr/local/lib/libicui18n.so.58 #3 0x2942d3ba in icu::LocaleCacheKey<icu::SharedCalendar>::createObject(void const*, UErrorCode&) const () from /usr/local/lib/libicui18n.so.58 #4 0x296d190f in icu::UnifiedCache::_get(icu::CacheKeyBase const&, icu::SharedObject const*&, void const*, UErrorCode&) const () from /usr/local/lib/libicuuc.so.58 #5 0x29438906 in void icu::UnifiedCache::get<icu::SharedCalendar>(icu::CacheKey<icu::SharedCalendar> const&, void const*, icu::SharedCalendar const*&, UErrorCode&) const () from /usr/local/lib/libicui18n.so.58 #6 0x29437d78 in void icu::UnifiedCache::getByLocale<icu::SharedCalendar>(icu::Locale const&, icu::SharedCalendar const*&, UErrorCode&) () from /usr/local/lib/libicui18n.so.58 #7 0x2942e90d in icu::Calendar::createInstance(icu::TimeZone*, icu::Locale const&, UErrorCode&) () from /usr/local/lib/libicui18n.so.58 #8 0x293ec0f1 in icu::SimpleDateFormat::construct(icu::DateFormat::EStyle, icu::DateFormat::EStyle, icu::Locale const&, UErrorCode&) () from /usr/local/lib/libicui18n.so.58 and David Chisnall tells me: This is quite surprising. On FreeBSD, this function should be provided by libcxxrt, not libsupc++. Please file a bug report with the FreeBSD gcc maintainer - it looks as if you’ve somehow ended up with a program linking both libc++ from base and libstdc++ from ports, and the libstdc++ from ports is incorrectly using its own internal libsupc++ instead of the system-provided libcxxrt (which I wrote, so can help debugging a bit better).
GCC really is supposed to work with libstdc++, what is being put together on FreeBSD is not tested anywhere else (and not supported by upstream from all I know). Still, perhaps someone on toolchain@ can lend a helping hand?
If I were trying to help someone with this I'd want to see the full text for the compile and link commands, be they from personal builds or from port builds. That would be part of a "how to reproduce" set of instructions. There might be ldd output that would be appropriate as well.
(In reply to Gerald Pfeifer from comment #1) > GCC really is supposed to work with libstdc++, I guess, comment 0 alludes to base r233749 trick[1]. If ported to lang/gcc* it'd make USE_GCC usage in C++ ports less dangerous on CLANG_IS_CC architectures as Clang on FreeBSD 10+ defaults to libc++. OTOH, Clang on FreeBSD has broken support for libstdc++ from ports i.e., --gcc-toolchain=/usr/local/lib/gccN is nop. [1] https://wiki.freebsd.org/NewC++Stack#Mixing_Libraries_using_Libc.2B-.2B-_and_Libstdc.2B-.2B-
(In reply to Gerald Pfeifer from comment #1) Using libstdc++ is moderately dangerous on FreeBSD, as it is not the system C++ standard library. It is only moderately dangerous though, because it uses different symbol names for the standard library symbols and so should result in a hard linker error if attempting to use it for a public interface with something linked against libc++. Using libsupc++; however, is very dangerous. It exports symbols with the same names as those exported by libcxxrt. These are likely to interfere in ways that cause exciting forms of breakage. The gcc ports should not be installing a libstdc++ that links to libsupc++. As to clang not working with libstdc++, last time I tried it -stdlib=libstdc++ worked, and would pick up the correct libstdc++ if the correct -I and -L flags were passed. If this doesn't work, please file a bug report. As far as I know, --gcc-toolchain is a compile-time configuration option (from the old and now removed autoconf LLVM build system) to specify the default path for headers, not a compiler flag.
I suspect this mix of infrastructures ties in to why standard c++ threading fails under the likes of g++6 compiles while the code works when compiled and linked via system clang++ 5. The infrastructure issues may extend to the libgcc_s that is used as well. (The program here is just one that I happen to have around, not minimized, but standard C++ code only.) Starting without an explicit -pthread : g++6 -std=c++14 -Wpedantic -Wall -Wl,-rpath=/usr/local/lib/gcc6 -O2 cpp_clocks_investigation.cpp (So no -pthread explicitly.) Note the lack of both libthr.so.3 and libcxxrt.so.1 in the below. Also the libgcc_s being from gcc6 materials. # ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000) libm.so.5 => /lib/libm.so.5 (0x800bd9000) libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000) libc.so.7 => /lib/libc.so.7 (0x80101d000) leads to: static inline int __gthread_create (__gthread_t *__threadid, void *(*__func) (void*), void *__args) { return __gthrw_(pthread_create) (__threadid, NULL, __func, __args); } getting SIGSEGV from pthread_create not having a good address. With -pthread the a.out produced gets a SIGSEGV in infrustrature. Showing similar to the above information: g++6 -std=c++14 -Wpedantic -Wall -pthread -Wl,-rpath=/usr/local/lib/gcc6 -O2 cpp_clocks_investigation.cpp Note the libthr.so.3 but the lack of libcxxrt.so.1 in the below. Also the libgcc_s being from gcc6 materials. # ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc6/libstdc++.so.6 (0x800844000) libm.so.5 => /lib/libm.so.5 (0x800bd9000) libgcc_s.so.1 => /usr/local/lib/gcc6/libgcc_s.so.1 (0x800e06000) libthr.so.3 => /lib/libthr.so.3 (0x80101d000) libc.so.7 => /lib/libc.so.7 (0x801245000) (run in /usr/local/bin/gdb :) Thread 11 received signal SIGSEGV, Segmentation fault. [Switching to LWP 100288 of process 18022] uw_frame_state_for (context=context@entry=0x7fffdfdfce20, fs=fs@entry=0x7fffdfdfcb70) at /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249 1249 return MD_FALLBACK_FRAME_STATE_FOR (context, fs); (gdb) bt #0 uw_frame_state_for (context=context@entry=0x7fffdfdfce20, fs=fs@entry=0x7fffdfdfcb70) at /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249 #1 0x0000000800e1602b in _Unwind_ForcedUnwind_Phase2 (exc=exc@entry=0x80069cc30, context=context@entry=0x7fffdfdfce20) at /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155 #2 0x0000000800e16364 in _Unwind_ForcedUnwind (exc=0x80069cc30, stop=0x801033450 <thread_unwind_stop>, stop_argument=<optimized out>) at /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207 #3 0x00000008010332b3 in _Unwind_ForcedUnwind (ex=<optimized out>, stop_func=0x7fffdfdfc948, stop_arg=0x80069ca00) at /usr/src/lib/libthr/thread/thr_exit.c:106 #4 thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172 #5 _pthread_exit_mask (status=<optimized out>, mask=<optimized out>) at /usr/src/lib/libthr/thread/thr_exit.c:254 #6 0x00000008010330db in _pthread_exit (status=0x80069ca00) at /usr/src/lib/libthr/thread/thr_exit.c:206 #7 0x0000000801025c0d in thread_start (curthread=0x80069ca00) at /usr/src/lib/libthr/thread/thr_create.c:289 #8 0x00007fffdfbfd000 in ?? () Backtrace stopped: Cannot access memory at address 0x7fffdfdfd000 Note #3 -> #4 goes from: /usr/src/lib/libthr/thread/thr_exit.c: to: /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc So: from system libthr to gcc6's libgcc . System clang++ 5 with -pthread (link fails without it): clang++ -std=c++14 -Wpedantic -Wall -pthread cpp_clocks_investigation.cpp # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x8008a6000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b72000) libm.so.5 => /lib/libm.so.5 (0x800d90000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800fbd000) libthr.so.3 => /lib/libthr.so.3 (0x8011d3000) libc.so.7 => /lib/libc.so.7 (0x8013fb000) This a.out runs to completion just fine.
(In reply to Mark Millard from comment #5) To avoid confusion from a typing/editing error. . . "Note #3 -> #4 goes from" in the reference to the g++6 based a.out backtrace should have been: "Note #3 -> #2 goes from".
(In reply to Mark Millard from comment #5) FYI: An older report of the threading issues with the tiny program: static void f() {} int main(int, const char* []) { auto a0{ std::async( std::launch::async, f ) }; a0.get(); return 0; } is bugzilla 212330 .
(In reply to Mark Millard from comment #7) Looking at its details bugzilla 212330 is not a good example for here in 221288. For one the failing context was armv6 and amd64 worked. The failing thread call sequence is not a match either. It was for __gthread_once going to _pthread_once (so gthr-default.h into the system libthr).
(In reply to Mark Millard from comment #6) Returning to a g++6 based a.out back trace for the C++ threading to show some infrastructure usage involved: Thread 12 received signal SIGSEGV, Segmentation fault. [Switching to LWP 100277 of process 18243] uw_frame_state_for (context=context@entry=0x7fffdfbfbe20, fs=fs@entry=0x7fffdfbfbb70) at /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249 1249 return MD_FALLBACK_FRAME_STATE_FOR (context, fs); (gdb) disass Dump of assembler code for function uw_frame_state_for: . . . 0x0000000800e14a6e <+94>: callq 0x800e08870 <_Unwind_Find_FDE@plt> 0x0000000800e14a73 <+99>: test %rax,%rax 0x0000000800e14a76 <+102>: mov %rax,%r12 0x0000000800e14a79 <+105>: je 0x800e14bd8 <uw_frame_state_for+456> . . . 0x0000000800e14bd8 <+456>: mov 0x98(%r15),%rax => 0x0000000800e14bdf <+463>: cmpl $0x247c8d48,(%rax) 0x0000000800e14be5 <+469>: je 0x800e14e62 <uw_frame_state_for+1106> 0x0000000800e14beb <+475>: nopl 0x0(%rax,%rax,1) 0x0000000800e14bf0 <+480>: mov $0x5,%eax 0x0000000800e14bf5 <+485>: add $0x38,%rsp 0x0000000800e14bf9 <+489>: pop %rbx 0x0000000800e14bfa <+490>: pop %rbp 0x0000000800e14bfb <+491>: pop %r12 0x0000000800e14bfd <+493>: pop %r13 0x0000000800e14bff <+495>: pop %r14 0x0000000800e14c01 <+497>: pop %r15 0x0000000800e14c03 <+499>: retq . . . which matches up with the 0x247c8d48 comparison code in: /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/config/i386/freebsd-unwind.h in the source: . . . #ifdef __x86_64__ #define MD_FALLBACK_FRAME_STATE_FOR x86_64_freebsd_fallback_frame_state static _Unwind_Reason_Code x86_64_freebsd_fallback_frame_state (struct _Unwind_Context *context, _Unwind_FrameState *fs) { struct sigframe *sf; long new_cfa; /* Prior to FreeBSD 9, the signal trampoline was located immediately before the ps_strings. To support non-executable stacks on AMD64, the sigtramp was moved to a shared page for FreeBSD 9. Unfortunately this means looking frame patterns again (sys/amd64/amd64/sigtramp.S) rather than using the robust and convenient KERN_PS_STRINGS trick. <pc + 00>: lea 0x10(%rsp),%rdi <pc + 05>: pushq $0x0 <pc + 17>: mov $0x1a1,%rax <pc + 14>: syscall If we can't find this pattern, we're at the end of the stack. */ if (!( *(unsigned int *)(context->ra) == 0x247c8d48 && *(unsigned int *)(context->ra + 4) == 0x48006a10 && *(unsigned int *)(context->ra + 8) == 0x01a1c0c7 && *(unsigned int *)(context->ra + 12) == 0x050f0000 )) return _URC_END_OF_STACK; . . . where: (gdb) print context->ra $2 = (void *) 0x7fffdf7fb000 (gdb) print *(unsigned*)(context->ra) Cannot access memory at address 0x7fffdf7fb000
I looked up the tree from my lang/gcc6 build and find that its libstdc++.a is linked in part via a bunch of: .libs/libstdc++.lax/libsupc++convenience.a/*.o files. Specifically: libtool: link: /usr/local/x86_64-portbld-freebsd12.0/bin/ar rc .libs/libstdc++.a compatibility.o compatibility-debug_list.o compatibility-debug_list-2.o compatibility-c++0x.o compatibility-atomic-c++0 x.o compatibility-thread-c++0x.o compatibility-chrono.o compatibility-condvar.o .libs/libstdc++.lax/libsupc++convenience.a/del_op.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo2.o .libs/libstdc++. lax/libsupc++convenience.a/bad_typeid.o .libs/libstdc++.lax/libsupc++convenience.a/dyncast.o .libs/libstdc++.lax/libsupc++convenience.a/eh_throw.o .libs/libstdc++.lax/libsupc++convenience.a/guard.o .l ibs/libstdc++.lax/libsupc++convenience.a/new_opv.o .libs/libstdc++.lax/libsupc++convenience.a/eh_tm.o .libs/libstdc++.lax/libsupc++convenience.a/vterminate.o .libs/libstdc++.lax/libsupc++convenience.a /bad_array_new.o .libs/libstdc++.lax/libsupc++convenience.a/new_handler.o .libs/libstdc++.lax/libsupc++convenience.a/pbase_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/bad_array_length.o .li bs/libstdc++.lax/libsupc++convenience.a/si_class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/eh_exception.o .libs/libstdc++.lax/libsupc++convenience.a/new_opvnt.o .libs/libstdc++.lax/libsup c++convenience.a/eh_call.o .libs/libstdc++.lax/libsupc++convenience.a/bad_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/eh_aux_runtime.o .libs/libstdc++.lax/libsupc++convenience.a/bad_cast.o .lib s/libstdc++.lax/libsupc++convenience.a/pointer_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/eh_globals.o .libs/libstdc++.lax/libsupc++convenience.a/pure.o .libs/libstdc++.lax/libsupc++conven ience.a/fundamental_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/new_op.o .libs/libstdc++.lax/libsupc++convenience.a/del_ops.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_arm.o .libs/l ibstdc++.lax/libsupc++convenience.a/eh_arm.o .libs/libstdc++.lax/libsupc++convenience.a/guard_error.o .libs/libstdc++.lax/libsupc++convenience.a/array_type_info.o .libs/libstdc++.lax/libsupc++convenie nce.a/vmi_class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/atexit_thread.o .libs/libstdc++.lax/libsupc++convenience.a/eh_term_handler.o .libs/libstdc++.lax/libsupc++convenience.a/eh_unex_h andler.o .libs/libstdc++.lax/libsupc++convenience.a/class_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/hash_bytes.o .libs/libstdc++.lax/libsupc++convenience.a/del_opv.o .libs/libstdc++.lax/l ibsupc++convenience.a/eh_terminate.o .libs/libstdc++.lax/libsupc++convenience.a/del_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/cp-demangle.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvnt .o .libs/libstdc++.lax/libsupc++convenience.a/vec.o .libs/libstdc++.lax/libsupc++convenience.a/del_opvs.o .libs/libstdc++.lax/libsupc++convenience.a/nested_exception.o .libs/libstdc++.lax/libsupc++con venience.a/eh_alloc.o .libs/libstdc++.lax/libsupc++convenience.a/eh_ptr.o .libs/libstdc++.lax/libsupc++convenience.a/tinfo.o .libs/libstdc++.lax/libsupc++convenience.a/enum_type_info.o .libs/libstdc++ .lax/libsupc++convenience.a/eh_type.o .libs/libstdc++.lax/libsupc++convenience.a/function_type_info.o .libs/libstdc++.lax/libsupc++convenience.a/eh_personality.o .libs/libstdc++.lax/libsupc++convenien ce.a/eh_catch.o .libs/libstdc++.lax/libsupc++convenience.a/new_opnt.o .libs/libstdc++.lax/libsupc++convenience.a/pmem_type_info.o . . . (more from elsewhere) . . . Similarly .libs/libstdc++.so.6.0.22 's link lists: ../libsupc++/.libs/libsupc++convenience.a and has: -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/x86_64-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs For example: libtool: link: /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/xgcc -shared-libgcc -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc -nostdinc++ -L/usr/obj/portswork/usr/ports/lang/ gcc6/work/.build/x86_64-portbld-freebsd12.0/libstdc++-v3/src -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/x86_64-portbld-freebsd12.0/libstdc++-v3/src/.libs -L/usr/obj/portswork/usr/ports/lang/ gcc6/work/.build/x86_64-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-portbld-freebsd12.0/bin/ -B/usr/local/x86_64-portbld-freebsd12.0/lib/ -isystem /usr/local/x86_64-portbld-fr eebsd12.0/include -isystem /usr/local/x86_64-portbld-freebsd12.0/sys-include -fPIC -DPIC -D_GLIBCXX_SHARED -shared -nostdlib /usr/lib/crti.o /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gc c/crtbeginS.o .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x .o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a ../src/c++98/.libs/libc++98convenience.a ../src/c++11/.libs/libc++11conveni ence.a -Wl,--no-whole-archive -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/x86_64-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/x86_64- portbld-freebsd12.0/libstdc++-v3/src -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/x86_64-portbld-freebsd12.0/libstdc++-v3/src/.libs -lm -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./g cc -L/usr/local/x86_64-portbld-freebsd12.0/bin -L/usr/local/x86_64-portbld-freebsd12.0/lib -lc -lgcc_s /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./gcc/crtendS.o /usr/lib/crtn.o -B/usr/obj/po rtswork/usr/ports/lang/gcc6/work/.build/./gcc -B/usr/local/x86_64-portbld-freebsd12.0/bin/ -B/usr/local/x86_64-portbld-freebsd12.0/lib/ -Wl,-O1 -Wl,-z -Wl,relro -Wl,--gc-sections -Wl,--version-script= libstdc++-symbols.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.22 where .libs/libsupc++convenience.a was linked via: libtool: link: /usr/local/x86_64-portbld-freebsd12.0/bin/ar rc .libs/libsupc++convenience.a array_type_info.o atexit_arm.o atexit_thread.o bad_alloc.o bad_array_length.o bad_array_new.o bad_cast.o bad_typeid.o class_type_info.o del_op.o del_ops.o del_opnt.o del_opv.o del_opvs.o del_opvnt.o dyncast.o eh_alloc.o eh_arm.o eh_aux_runtime.o eh_call.o eh_catch.o eh_exception.o eh_globals.o eh_personality.o eh_ptr.o eh_term_handler.o eh_terminate.o eh_tm.o eh_throw.o eh_type.o eh_unex_handler.o enum_type_info.o function_type_info.o fundamental_type_info.o guard.o guard_error.o hash_bytes.o nested_exception.o new_handler.o new_op.o new_opnt.o new_opv.o new_opvnt.o pbase_type_info.o pmem_type_info.o pointer_type_info.o pure.o si_class_type_info.o tinfo.o tinfo2.o vec.o vmi_class_type_info.o vterminate.o cp-demangle.o It appears that for libstdc++.so use (dynamic linking) libsupc++ is at last partially bundled in libstdc++.so . This also seems to be true of libstdc++.a for static linking, even if libsupc++.a contains more.
Trying my standard-C++ program that uses C++ threads in a more modern context (head -r322287, lang/gcc7) in an amd64 context under a Virtual Box virtual machine (that is running on Windows 10 Pro). . . # g++7 -std=c++14 -Wpedantic -Wall -pthread -Wl,-rpath=/usr/local/lib/gcc7 -O2 cpp_clocks_investigation.cpp # ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc7/libstdc++.so.6 (0x800844000) libm.so.5 => /lib/libm.so.5 (0x800bd8000) libgcc_s.so.1 => /usr/local/lib/gcc7/libgcc_s.so.1 (0x800e05000) libthr.so.3 => /lib/libthr.so.3 (0x80101c000) libc.so.7 => /lib/libc.so.7 (0x801244000) # ./a.out . . . (omitted) . . . Segmentation fault (core dumped) # g++7 -std=c++14 -Wpedantic -Wall -pthread -O2 cpp_clocks_investigation.cpp# ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc7/libstdc++.so.6 (0x800844000) libm.so.5 => /lib/libm.so.5 (0x800bd8000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800e05000) libthr.so.3 => /lib/libthr.so.3 (0x80101b000) libc.so.7 => /lib/libc.so.7 (0x801243000) # ./a.out . . . (omitted) . . . End of clock tests. So it worked for /lib/libgcc_s.so.1 but not for /usr/local/lib/gcc7/libgcc_s.so.1 and I must have been wrong about /lib/libcxxrt.so.1 being what mattered. This threading example is a context where -Wl,-rpath=/usr/local/lib/gcc7 prevents correct operation because of cross library dependencies on implementation details of the build-time context vs. the mismatched runtime context for libthr.so.3 vs. libgcc_s.so.1 . # clang++ -std=c++14 -Wpedantic -Wall -pthread -O2 cpp_clocks_investigation.cpp # ldd a.out a.out: libc++.so.1 => /usr/lib/libc++.so.1 (0x800844000) libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800b10000) libm.so.5 => /lib/libm.so.5 (0x800d2e000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800f5b000) libthr.so.3 => /lib/libthr.so.3 (0x801171000) libc.so.7 => /lib/libc.so.7 (0x801399000) # ./a.out . . . (omitted) . . . End of clock tests. So this also worked. Again /lib/libthr.so.3 and /lib/libgcc_s.so.1 go together just fine.
Expired port (gcc5) removed, please re-open for gcc6 if this still relevant.