After installing shared-mime-info, a QA rule is installed which after each package runs a QA check through update-mime-database. This crashes on Darwin 23 on M2: dyld[5129]: Symbol not found: __ZNKSt10filesystem7__cxx1118directory_iteratordeEv Referenced from: <5FF6116C-A70B-33AF-B7F5-8F8BFE7D5944> /Users/leio/Gentoo/usr/bin/update-mime-database Expected in: <BDA653BA-55A9-3EE4-8EB8-6992AEE8D325> /usr/lib/libstdc++.6.dylib /Users/leio/Gentoo/usr/lib/portage/python3.11/postinst-qa-check.d/50xdg-utils: line 107: 5129 Abort trap: 6 update-mime-database "${d}" The worrying thing is - what else using libstdc++ might be crashing? I don't have much C++ things installed yet.
Portage 3.0.56-prefix (python 3.11.7-final-0, prefix/darwin/macos/14.0/arm64/gcc, gcc-13, unavailable, 23.2.0 arm64) ================================================================= System Settings ================================================================= System uname: macOS-10.16-arm64-arm-64bit Timestamp of repository gentoo_prefix: Sat, 03 Feb 2024 09:56:25 +0000 Head commit of repository gentoo_prefix: b8ea4cc727d3c70afcd84962eb51db379f2a15da sh bash 5.2_p26 app-misc/pax-utils: 1.3.7::gentoo_prefix app-shells/bash: 5.2_p26::gentoo_prefix dev-build/autoconf: 2.72-r1::gentoo_prefix dev-build/automake: 1.16.5-r2::gentoo_prefix dev-build/cmake: 3.28.2::gentoo_prefix dev-build/libtool: 2.4.7-r2::gentoo_prefix dev-build/make: 4.4.1-r1::gentoo_prefix dev-build/meson: 1.3.1-r1::gentoo_prefix dev-lang/perl: 5.38.2-r1::gentoo_prefix dev-lang/python: 3.11.7::gentoo_prefix sys-apps/baselayout: 2.14-r1::gentoo_prefix sys-devel/binutils-config: 5.1-r9::gentoo_prefix sys-devel/gcc: 13.2.0::gentoo_prefix sys-devel/gcc-config: 2.7-r1::gentoo_prefix Repositories: gentoo_prefix location: /Users/leio/Gentoo/var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.prefix.bitzolder.nl/gentoo-portage-prefix priority: -1000 aliases: gentoo volatile: True sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: no sync-rsync-verify-max-age: 3 ACCEPT_KEYWORDS="~arm64-macos" ACCEPT_LICENSE="@FREE" CBUILD="arm64-apple-darwin23" CFLAGS=" -O2 -pipe" CHOST="arm64-apple-darwin23" CONFIG_PROTECT="/Users/leio/Gentoo/etc /etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/Users/leio/Gentoo/etc/env.d /etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild" CONFIG_SHELL="/Users/leio/Gentoo/bin/bash" CXXFLAGS=" -O2 -pipe" DISTDIR="/Users/leio/Gentoo/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live case-insensitive-fs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news nostrip parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sfperms strict unknown-features-warn unmerge-logs unmerge-orphans unprivileged" FFLAGS="" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distfiles.prefix.bitzolder.nl/prefix" LDFLAGS="-Wl,-dead_strip_dylibs" LEX="flex" MAKEOPTS="-j24" PKGDIR="/Users/leio/Gentoo/var/cache/binpkgs" PORTAGE_CONFIGROOT="/Users/leio/Gentoo/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/Users/leio/Gentoo/var/tmp" SHELL="/Users/leio/Gentoo/bin/zsh" USE="aqua arm64-macos bzip2 coreaudio gdbm ipv6 ncurses nls objc objc++ prefix prefix-guest readline ssl test-rust unicode zlib" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="aes crc32 edsp neon sha1 sha2 v4 v5 v6 v7 v8 vfp vfp-d32 vfpv3 vfpv4" ELIBC="Darwin" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 ntrip navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" INPUT_DEVICES="libinput" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby31" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LANG, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS ================================================================= Package Settings ================================================================= x11-misc/shared-mime-info-2.4::gentoo_prefix was built with the following: USE="(prefix) (prefix-guest) -test" FEATURES="qa-unresolved-soname-deps protect-owned binpkg-multi-instance preserve-libs multilib-strict distlocks pkgdir-index-trusted nostrip unmerge-orphans sfperms config-protect-if-modified binpkg-logs merge-sync buildpkg-live unmerge-logs case-insensitive-fs unknown-features-warn ebuild-locks binpkg-docompress fixlafiles assume-digests unprivileged pid-sandbox binpkg-dostrip network-sandbox strict ipc-sandbox parallel-fetch news"
this may be because of gcc-13, it should've used GCC's own libstdc++.dylib from usr/lib/gcc/arm64-apple-darwin22/13/
Created attachment 885816 [details] shared-mime-info build.log Here's the build.log of shared-mime-info, in case that sheds any light on why it seems to pick up system libstdc++ by runtime linker later.
CCing toolchain for any GCC-13 thoughts too then per comment #2
prefix specific problem in any case
fwiw can you run otool -L on your usr/bin/update-mime-database?
% otool -L Gentoo/usr/bin/update-mime-database Gentoo/usr/bin/update-mime-database: /Users/leio/Gentoo/usr/lib/libglib-2.0.0.dylib (compatibility version 7801.0.0, current version 7801.4.0) /Users/leio/Gentoo/usr/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0) /Users/leio/Gentoo/usr/lib/libxml2.2.dylib (compatibility version 15.0.0, current version 15.5.0) @rpath/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.32.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1) Looks like it hasn't populated RPATH right maybe, would be my guess?
scanmacho --rpath should be able to tell
I've got the same problem here, and RPATH is empty, I suspect it's the linker wrapper doing something wrong
the funny thing is that in build tree, rpaths are in the object, but in the install tree, they are wiped, so looks like meson/ninja do something "smart", but it's black magic to me at this point
Yup, meson "fixes" rpath by deleting all of them. Great idea.
Meson internally adds a whole bunch of rpath entries in the build tree, with the primary objective of making the program run "uninstalled" or during the testsuite, including with access to directories inside the builddir. It doesn't rely on ld.so.conf, and it doesn't rely on exporting $LD_LIBRARY_PATH -- it injects then via RPATH directly. During installation, it cleans up these uninstalled/test entries, but does not touch entries from user or dependency defined -rpath arguments. What usually adds the GCC directory in Gentoo Prefix? Is it e.g. a GCC spec definition?
gcc and the linker-wrapper do, that's the whole reason these entries are set, I'm not sure I understand why meson is trying to "cleanup", build paths should never be stored in rpath
> I'm not sure I understand why meson is trying to "cleanup", build paths should never be stored in rpath Your opinion has been noted and respectfully rejected as exceedingly impractical. Meson will continue to store build paths in the rpath, whatever else happens.
I understand, but it still means meson produces broken binaries.
You're fixating on the wrong part. The question is why Meson removed them here, not "Meson should never remove any".
ok, why did meson remove them here?
That's what we are trying to figure out.
I have explained what meson does, why it does it, and how you can control what it does. Your only response is to throw names around, say meson shouldn't be doing something without explaining why you think it shouldn't be doing it, and claim things are broken. Despite your failure to cc me as either the dev-build/meson maintainer or the upstream meson maintainer, I have spotted the bug anyway and joined in to attempt to have an honest discussion with you about what Prefix needs and how it could be handled better, but this is a two way street. I'm ready whenever you are. If you are.
Hmm, not sure. You explained meson tries to make a program work "uninstalled", which relies on something like rpath, which not all platforms, or versions of platforms support. But that's fine, I guess. Because one could always use some horrific override *_PATH thing, which you for good reasons try to avoid if you have to. No problems here. What I see is that the object in the build tree has a bunch of rpaths, as I expect them, then when installed it has none. I'm saying I believe meson shouldn't do that, because it breaks binaries. I believe this very bug shows that. Is that throwing names around? I didn't CC any meson maintainer (yet), because I started to look into this issue, and try to see if I could understand what meson is trying to do, and then report a bug upsteam (at meson) with a proper and detailed explanation of what happens, and why it isn't what I would expect, and hopefully with a patch to remedy the situation. You somehow got notified and jumped on here. Well, that's actually very nice of you, but now we end up in this kind of ugly discussion, which I didn't want to have. I just wanted to see if we could come to an agreement once I fully understood why meson is doing what it is doing. So, you have found something, which is really nice. Thank you for that, what can I do to help you? Do you need to test something, do you need something explained on Prefix toolchain? Thanks
(In reply to Fabian Groffen from comment #20) > What I see is that the object in the build tree has a bunch of rpaths, as I > expect them, then when installed it has none. I'm saying I believe meson > shouldn't do that, because it breaks binaries. I believe this very bug > shows that. Well, it has to remove unsafe rpaths, i.e. any rpath that was generated on the build machine in order to make uninstalled / test usage work. Consider, for example, distros where packages are built in ~/packages/foobar/ and extracted to ~/packages/PN/workdir/PN-PV/ When building the package, rpaths are generated for /home/jessica/packages/foobar/workdir/foobar-1.0 The result is built into a binary package and distributed via the package manager channels to all users of $DISTRO, which means that all users of $DISTRO can install a program that will attempt to read its libraries from the "jessica" user's home directory. This is a CVE: on shared user systems, one simply requests an account with the username "jessica" and gains the ability to trick other users into running arbitrary attack code. What about on Gentoo, if a binhost builds packages with a PORTAGE_TMPDIR that is different from the one on end user machines? My /var/tmp/portage is not writable by all users, but /var/tmp is -- and if I changed it to /var/lib/portage/tmp then does that mean that any user can now create files in /var/tmp/portage that clash with the rpaths produced by a binhost? So, rpaths that are only meant to be used for uninstalled / test usage at build time do in fact need to be removed at install time. The question is then not whether rpaths should be removed, but *which* rpaths should be removed. > Is that throwing names around? I was thinking of something else, but... > I didn't CC any meson maintainer (yet), because I started to look into this > issue, and try to see if I could understand what meson is trying to do, and > then report a bug upsteam (at meson) with a proper and detailed explanation > of what happens, and why it isn't what I would expect, and hopefully with a > patch to remedy the situation. Ok, noted. :) Then I am still happy to provide insights that can save you a bit of effort in understanding what meson is trying to do, and you can open the ticket on https://github.com/mesonbuild/meson/issues once we have a clearer idea of what you want to propose.
One thing that springs to mind is that if there is some way meson can detect what rpaths are naturally created by $CC or $CXX including potentially any that are included in a shell script wrapper around the "real" compiler executable, meson could make sure to avoid trampling on that.
seems related to https://github.com/mesonbuild/meson/issues/12045 https://github.com/mesonbuild/meson/issues/12288 https://github.com/mpv-player/mpv/issues/13628 all similar of nature where RPATH entries unexpectedly disappear.
(In reply to Eli Schwartz from comment #22) > One thing that springs to mind is that if there is some way meson can detect > what rpaths are naturally created by $CC or $CXX including potentially any > that are included in a shell script wrapper around the "real" compiler > executable, meson could make sure to avoid trampling on that. You believe you can't because it depends on input/mode/execution/flags etc. What you /can/ do, is compare what you get after compiling with what you added yourself to the link-line. This is non-Prefix specific, as indicated in the meson issues, I linked. I suggest we continue the discussion on meson 12045 on how to fix this. Thanks.
s/You believe/I believe/
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=77fa58d79b6f22e7095cf4bcdb2a417c446eade4 commit 77fa58d79b6f22e7095cf4bcdb2a417c446eade4 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2024-03-27 17:46:56 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2024-03-27 17:46:56 +0000 dev-build/meson-1.4.0-r1: add path to unbreak Darwin builds Submitted upstream, https://github.com/mesonbuild/meson/pull/13012 in the meanwhile unbreak Darwin hosts. Closes: https://bugs.gentoo.org/923706 Signed-off-by: Fabian Groffen <grobian@gentoo.org> dev-build/meson/Manifest | 3 + .../meson/files/meson-1.2.1-python-path.patch | 26 +++ .../meson/files/meson-1.4.0-darwin-rpath.patch | 101 ++++++++++++ dev-build/meson/meson-1.4.0-r1.ebuild | 181 +++++++++++++++++++++ 4 files changed, 311 insertions(+)
Thanks for the investigation! This is merged upstream and queued for the next point release, at which point we can remove the Gentoo-specific backport.
yup, thanks
