>>> Configuring source in /var/tmp/portage/dev-ruby/llhttp-ffi-0.4.0/work ... * Running configure phase for ruby31 >>> Source configured. >>> Compiling source in /var/tmp/portage/dev-ruby/llhttp-ffi-0.4.0/work ... * Running compile phase for ruby31 rake aborted! LoadError: /usr/lib64/libjemalloc.so.2: cannot allocate memory in static TLS block - /usr/lib64/ruby/gems/3.1.0/gems/ffi-1.15.5/lib/ffi_c.so <internal:/usr/lib64/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require' <internal:/usr/lib64/ruby/site_ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require' ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.1_no_multilib-20230721-054004 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-10 [2] x86_64-pc-linux-gnu-13 * clang/llvm (if any): clang version 16.0.6 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/lib/llvm/16/bin Configuration file: /etc/clang/clang.cfg /usr/lib/llvm/16 16.0.6 Python 3.11.4 Available Ruby profiles: [1] ruby31 (with Rubygems) * Available Rust versions: [1] rust-bin-1.71.0 [2] rust-1.71.0 * The following VMs are available for generation-2: *) Eclipse Temurin JDK 17.0.7_p7 [openjdk-bin-17] 2) Eclipse Temurin JDK 8.372_p07 [openjdk-bin-8] Available Java Virtual Machines: [1] openjdk-bin-8 [2] openjdk-bin-17 system-vm php cli (if any): go version go1.20.6 linux/amd64 HEAD of ::gentoo commit 98729499b3de06ae47d9991be4cfe3d7b089aee1 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Sat Jul 22 06:46:53 2023 +0000 2023-07-22 06:46:52 UTC emerge -qpvO dev-ruby/llhttp-ffi [ebuild N ] dev-ruby/llhttp-ffi-0.5.0 USE="-doc -test" RUBY_TARGETS="ruby31 -ruby30 -ruby32"
Created attachment 865950 [details] emerge-info.txt
Created attachment 865951 [details] dev-ruby:llhttp-ffi-0.4.0:20230722-122440.log
Created attachment 865952 [details] emerge-history.txt
Created attachment 865953 [details] environment
Created attachment 865954 [details] etc.clang.tar.xz
Created attachment 865955 [details] etc.portage.tar.xz
The situation is much worse: 1.) Exactly the same error happens for *many* ruby packages: Re-emerging about one-third of all dev-ruby packages I've installed fails with this error (dev-ruby/bundler, dev-ruby/did_you_mean, dev-ruby/kpegdev-ruby/minitest, dev-ruby/psych, dev-ruby/rss), re-emerging webkit-gtk (!) fails with this error, ... So ruby seems to be completely broken by that error. 2.) It's not specific to ruby 3.1. I'm using dev-lang/ruby-3.2.2-r4. 3.) My ruby-3.2.2-r4 ist built with -jemalloc. Hence, it should not use and should not depend on jemalloc.so at all. However, in all cases the error message explicitely mentions /usr/lib64/libjemalloc.so.2 (as shown in the original bug report). ldd /usr/bin/ruby32 does not list libjemalloc.so.2. So ruby is not linked against libjemalloc, but in spite of USE -jemalloc, obviously tries to dlopen libjemalloc at runtime?!
The culprit who dlopened libjemalloc was psych.so, but *not* /usr/lib64/ruby/3.2.0/x86_64-linux/psych.so from dev-lang/ruby (this one is clean w.r.t. libjemalloc). It was /usr/lib64/ruby/gems/3.2.0/gems/psych-5.1.0/lib/psych.so and /usr/lib64/ruby/gems/3.2.0/extensions/x86_64-linux/3.2.0/psych-5.1.0/psych.so from dev-ruby/psych. Simply re-emerging dev-ruby/psych failed with the jemalloc error, but unmerging it and then merging it again did the trick. Everything seems to work now, no more errors, no reference to libjemalloc.so in any ruby file. By the way: Do we really need both /usr/lib64/ruby/3.2.0/x86_64-linux/psych.so from dev-lang/ruby and .../psych.so from dev-ruby/psych, or is dev-ruby/psych redundant???
The jemalloc USE flag has been masked for dev-lang/ruby some time ago.
