Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 924150 - sys-devel/gcc with slibtool: libstdc++ missing _ZNSt18condition_variable4waitERSt11unique_lockISt5mutexE@GLIBCXX_3.4.11
Summary: sys-devel/gcc with slibtool: libstdc++ missing _ZNSt18condition_variable4wait...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: slibtool
  Show dependency tree
 
Reported: 2024-02-09 10:37 UTC by Agostino Sarubbo
Modified: 2024-09-25 19:29 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
build.log (build.log,56.02 KB, text/plain)
2024-02-09 10:37 UTC, Agostino Sarubbo
Details
nm output (file_924150.txt,20.90 KB, text/plain)
2024-02-09 11:18 UTC, Agostino Sarubbo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2024-02-09 10:37:48 UTC
https://blogs.gentoo.org/ago/2020/07/04/gentoo-tinderbox/

Issue: dev-dotnet/csharp-gentoodotnetinfo-1.1.1-r1 fails to compile.
Discovered on: amd64 (internal ref: slibtool_tinderbox)
System: SLIBTOOL-SYSTEM (https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#SLIBTOOL)

Info about the issue:
https://wiki.gentoo.org/wiki/Project:Tinderbox/Common_Issues_Helper#CF0014
Comment 1 Agostino Sarubbo gentoo-dev 2024-02-09 10:37:50 UTC
Created attachment 884598 [details]
build.log

build log and emerge --info
Comment 2 Maciej Barć gentoo-dev 2024-02-09 10:48:21 UTC
Anything special to note about this setup?
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2024-02-09 11:01:30 UTC
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?
Comment 4 Agostino Sarubbo gentoo-dev 2024-02-09 11:14:07 UTC
(In reply to Maciej Barć from comment #2)
> Anything special to note about this setup?

Just what reported into comment #0
Comment 5 Agostino Sarubbo gentoo-dev 2024-02-09 11:18:02 UTC
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
Comment 6 Maciej Barć gentoo-dev 2024-02-09 11:26:26 UTC
diffed it against my output (prebuilt SDK), they are the same
Comment 7 Alex Xu (Hello71) 2024-07-21 17:23:25 UTC
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
Comment 8 Larry the Git Cow gentoo-dev 2024-09-25 19:29:14 UTC
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(+)