| Summary: | sys-devel/gcc with slibtool: libstdc++ missing _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Agostino Sarubbo <ago> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alex_y_xu, dotnet, xgqt |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: | https://bugs.gentoo.org/show_bug.cgi?id=932245 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 765709 | ||
| Attachments: |
build.log
nm output |
||
|
Description
Agostino Sarubbo
2024-02-09 10:37:48 UTC
Created attachment 884598 [details]
build.log
build log and emerge --info
Anything special to note about this setup? ago: could you upload nm -D /opt/dotnet-sdk-bin-8.0/host/fxr/8.0.1/libhostfxr.so and nm -D /opt/dotnet-sdk-bin-8.0/host/fxr/8.0.1/libhostfxr.so | c++filt? (In reply to Maciej Barć from comment #2) > Anything special to note about this setup? Just what reported into comment #0 Created attachment 884599 [details] nm output (In reply to Sam James from comment #3) > ago: could you upload nm -D > /opt/dotnet-sdk-bin-8.0/host/fxr/8.0.1/libhostfxr.so > and nm -D /opt/dotnet-sdk-bin-8.0/host/fxr/8.0.1/libhostfxr.so | c++filt? attached diffed it against my output (prebuilt SDK), they are the same same issue affects firefox-bin, tor browser, etc. it can be worked around by preloading the symbol:
// g++ -shared -Wl,--version-script=<(<<<'GLIBCXX_3.4.11{};GLIBCXX_3.4.30{}GLIBCXX_3.4.11;') -Os -s -Wl,--as-needed -o condvar.so
// LD_PRELOAD=./condvar.so dotnet ...
#include <condition_variable>
namespace __gnu_cxx {
struct __nothrow_wait_cv : std::condition_variable
{
void wait(std::unique_lock<std::mutex>&) noexcept;
};
__attribute__((symver("_ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11")))
void
__nothrow_wait_cv::wait(std::unique_lock<std::mutex>& lock) noexcept
{
this->condition_variable::wait(lock);
}
}
the old version and new version are same, except old version has noexcept and new version doesn't.
when gcc is built with slibtool, libstdc++ is missing non-default versioned symbols. @ago could you check your libstdc++ is built with slibtool, and nm -D /usr/lib/gcc/x86_64-pc-linux-gnu/13/libstdc++.so.6 | grep -F _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=58128e2701881192e5d551d6b1d27bac3f6cde58 commit 58128e2701881192e5d551d6b1d27bac3f6cde58 Author: Eli Schwartz <eschwartz@gentoo.org> AuthorDate: 2024-09-25 17:51:52 +0000 Commit: Eli Schwartz <eschwartz@gentoo.org> CommitDate: 2024-09-25 18:22:23 +0000 toolchain.eclass: ban the use of rlibtool dev-build/slibtool provides an alternative implementation of libtool which is intended to hook itself into and replace the ltmain.sh-based ./libtool shell scripts installed into an autotools build system. It has some interesting quirks. In particular, it takes the idea of "packagers don't want to install libtool archives for random libraries because nobody uses them and pkg-config is better" and runs with it. It runs quite far with it, as it doesn't install them at all without a new flag passed to slibtool. This is redundant with our existing approach of deleting them in src_install when we know they are useless, and is downright broken in cases such as GCC, where the libtool archives are load-bearing and the resultant compiler is, in their absence, nonfunctional. slibtool supports a variety of wrappers to enable reasonable functionality which it by default disabled. The official recommendation is you are supposed to use "rlibtool" to replace ./libtool as it performs heuristics based on the generated config. But we actually need "rclibtool", which both respects the generated config and also generates the *.la archives and leaves it up to ebuilds to decide whether they should be removed. Raise a fatal error if the user has misconfigured slibtool. This prevents the user from building a broken and malformed GCC. Closes: https://bugs.gentoo.org/932245 Closes: https://bugs.gentoo.org/924150 Closes: https://bugs.gentoo.org/931268 Closes: https://bugs.gentoo.org/931279 Signed-off-by: Eli Schwartz <eschwartz@gentoo.org> Reviewed-by: Sam James <sam@gentoo.org> eclass/toolchain.eclass | 3 +++ 1 file changed, 3 insertions(+) |
