Bug 236344
| Summary: | [toolchain] gcc-built shared library crashes in static object constructors when dynamically loaded | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Yuri Victorovich <yuri> |
| Component: | misc | Assignee: | freebsd-toolchain (Nobody) <toolchain> |
| Status: | New --- | ||
| Severity: | Affects Only Me | CC: | dim, fernape, kib, marklmi26-fbsd, salvadore, theraven, val |
| Priority: | --- | ||
| Version: | 11.2-STABLE | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Bug Depends on: | |||
| Bug Blocks: | 259070 | ||
|
Description
Yuri Victorovich
2019-03-07 04:04:12 UTC
Any updates on this? cad/openvsp doesn't build with clang anymore due to bug #230888. It builds with gcc but it then segfaults with similar backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0000000802efba18 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1 (gdb) bt #0 0x0000000802efba18 in vtable for __cxxabiv1::__si_class_type_info () from /lib/libcxxrt.so.1 #1 0x0000000801a273e6 in __dynamic_cast () from /usr/local/lib/gcc9/libstdc++.so.6 #2 0x0000000801aa9e8e in bool std::has_facet<std::ctype<char> >(std::locale const&) () from /usr/local/lib/gcc9/libstdc++.so.6 #3 0x0000000801a9bbd4 in std::basic_ios<char, std::char_traits<char> >::_M_cache_locale(std::locale const&) () from /usr/local/lib/gcc9/libstdc++.so.6 #4 0x0000000801a9c070 in std::basic_ios<char, std::char_traits<char> >::init(std::basic_streambuf<char, std::char_traits<char> >*) () from /usr/local/lib/gcc9/libstdc++.so.6 #5 0x0000000801a3b463 in std::ios_base::Init::Init() () from /usr/local/lib/gcc9/libstdc++.so.6 #6 0x000000000049f60d in ?? () #7 0x000000080194846e in ?? () from /libexec/ld-elf.so.1 #8 0x00007fffffffc828 in ?? () #9 0x0000000801975800 in ?? () #10 0x0000000000000000 in ?? () Can you extract the minimal test case ? Yep, it involves a patch for cad/openvsp (to make it build with gcc). Should I open a different PR so I don't hijack this one? (In reply to Fernando Apesteguía from comment #3) Yes, please open a different PR. Done: bug #246488 I think that what Konstantin means with a minimal test case, is not a huge CAD port, but one or two .cpp files which can be independently compiled, to show the issue. That said, this seems like an issue with shared libraries initializing libstdc++'s iostream constructors twice. I guess the vtable pointer shows in the description and comment table is NULL? Did any of the original submitters check that? Encountered this in darktable (non-ports, just trying gcc to compare performance) as well. The only solution I've found is switching to libc++ via CXXFLAGS="-nostdinc++ -isystem /usr/include/c++/v1" and LDFLAGS="-L/tmp/somedir" where somedir is where you do ln -s /usr/lib/libc++.so libstdc++.so. The ports framework already supports this, see the gcc-c++11-lib section at the bottom of Mk/Uses/compiler.mk. (In reply to Greg V from comment #7) Just an FYI: In use of FreeBSD's libc++ from g++ I use, for example, from a specific context (not a port): CXX= g++11 -v -std=c++20 -Wpedantic -Wall -Wextra CXX+= -Wno-psabi -nostdinc -nostdinc++ \ -I/usr/include/c++/v1 -I/usr/include . . . LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s On aarch64 I've also use: -mno-outline-atomics I also sometimes need -Wl,-rpath=/usr/local/lib/gcc11 for things missing from the -lgcc_s . The context does not load any other .so's, however. For reference . . . My FreeBSD goes back to 2021-Jul-05: # uname -apKU FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #10 main-n247756-348c41d1815d-dirty: Mon Jul 5 10:23:55 PDT 2021 root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400025 1400025 The ports go back to 2021-Jun-19: # ~/fbsd-based-on-what-commit.sh branch: main merge-base: 7e413d93a62bb844a193e568fd8a1ba4834e5ea5 merge-base: CommitDate: 2021-06-19 00:23:12 +0000 7e413d93a62b (HEAD -> main, freebsd/main, freebsd/HEAD) graphics/mesa-devel: update to 21.1.b.3189 n549134 (--first-parent --count for merge-base) From the stack trace, it looks as if this is linking both from the base system libcxxrt.so and libstdc++.so from the gcc8 port. The version of libstdc++.so from the base system was modified to link libcxxrt.so but I believe the versions from ports embed libsupc++.a. Both libcxxrt and libsupc++ define the same symbols and so you end up with a mixture of them being called. In particular, you're mixing part of the `dynamic_cast` implementation from libsupc++ (frame #1) with part from libcxxrt (frame #0). This is very unlikely to work. The correct fix for this would be to make the GCC ports link libstdc++.so against libcxxrt.so instead of building libsupc++.a, but that probably requires some invasive changes to the build system. In general, mixing code linked against libc++ and libstdc++ is unlikely to work. There are three ways of fixing this: - Teach the libstdc++ build to use libcxxrt - Teach gcc to support -stdlib=libc++ - Use something like `-nostdinc++ -nodefaultlibs -isystem <install>/include/c++/v1 -lc++ -lcxxrt -lm -lc -lgcc_s -lgcc` when compiling / linking C++ things with gcc. *** Bug 269110 has been marked as a duplicate of this bug. *** (In reply to David Chisnall from comment #9) Some of the lang/gcc* ports were taught to support -stdlib=libc++ back in late 2022-Aug. |