https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207325
--- Comment #2 from Mark Millard <[email protected]> --- More comparisons/contrasts: Renaming the failing a.outs to: exception_test.clang++380 (requires libc++/libcxxrt) exception_test.g++49 exception_test.g++5 and using the g++ ones from a 11.0-CURRENT built via gcc 4.2.1 has them all working fine. (clang requires libraries not present and so is not tested this way.) On a 11.0-CURRENT built via gcc 4.2.1 producing a exception_test.g++421 and later using it on a clang 3.8.0 based projects/clang380-import -r295601 buildworld gets the SEGV. (It works fine in its original environment.) Using g++49 to make the following point about the working -Wl,rpath=? compiles vs. the other failing ones --via differencing ldd output under the clang 3.8.0 based buildworld: # diff exception_test.ldd_g++49_* 1c1 < exception_test.g++49: --- > exception_test.g++49_rpath: 4,5c4,5 < libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x419a1000) < libc.so.7 => /lib/libc.so.7 (0x419c0000) --- > libgcc_s.so.1 => /usr/local/lib/gcc49/libgcc_s.so.1 (0x419a1000) > libc.so.7 => /lib/libc.so.7 (0x419c4000) # All the falling exception_test.* variants bind: libgcc_s.so.1 => /lib/libgcc_s.so.1 clang++ output or g++ output does not matter: No exception_test.* so bound avoids the SEGV. All of the libgcc_s.so.1 => /usr/local/lib/gcc*/libgcc_s.so.1 bindings work fine. I will note that the exception_test.g++* ones produced from the clang 3.8.0 buildworld context without -Wl,-rpath=? use (in that same buildworld environment): ELF ldconfig path: /lib /usr/lib /usr/lib/compat /usr/local/lib /usr/local/lib/gcc49 /usr/local/lib/gcc5 /usr/local/lib/gcc6 to bind: libstdc++.so.6 => /usr/local/lib/gcc49/libstdc++.so.6 but the exception_test.clang++380 example does not use that library yet still has the SEGV problem. It is libgcc_s.so.1 that makes the difference. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "[email protected]"
