Created attachment 803242 [details] build.log I've attached an example build.log from a failure with app-misc/pax-utils-1.3.5. meson.build:1:0: ERROR: Unable to detect linker for compiler `x86_64-apple-darwin21-gcc -Wl,--version -march=native -O2 -pipe -Wl,-dead_strip_dylibs` stdout: xtools-2.2.4 ld (Gentoo binutils-apple-8.2.1-r101) Based on Apple Inc. ld64-274.2 configured to support archs: ppc ppc64 i386 x86_64 x86_64h armv6 armv6m armv7 armv7s armv7m armv7em arm64 TAPI support using: tapilite based on Apple TAPI version 1000.10.8 (https://github.com/grobian/darwin-xtools.git) stderr: collect2 version 12.1.0 /Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0/../../../../x86_64-apple-darwin21/bin/ld -dynamic -arch x86_64 -macosx_version_min 12.0 -o a.out -L/Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0 -L/Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0/../../../../x86_64-apple-darwin21/lib -L/Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0/../../.. --version -dead_strip_dylibs -lemutls_w -lgcc -lSystem -no_compact_unwind -rpath @loader_path -rpath /Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0 -rpath /Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0/../../../../x86_64-apple-darwin21/lib -rpath /Users/sam/Gentoo/usr/lib/gcc/x86_64-apple-darwin21/12.1.0/../../.. A full log can be found at /Users/sam/Gentoo/var/tmp/portage/app-misc/pax-utils-1.3.5/work/pax-utils-1.3.5-build/meson-logs/meson-log.txt * ERROR: app-misc/pax-utils-1.3.5::gentoo_prefix failed (configure phase): * (no error message)
Created attachment 803245 [details] meson-log.txt
Portage 3.0.34 (python 3.10.4-final-0, prefix/darwin/macos/12.0/x64/gcc, gcc-12.1.0, unavailable, 21.6.0 x86_64) ================================================================= System uname: macOS-12.5.1-x86_64-i386-64bit Timestamp of repository gentoo_prefix: Sun, 04 Sep 2022 21:27:08 +0000 Head commit of repository gentoo_prefix: 6c9e523e263c2c8bce11f02aa00fee7b8d572339 sh bash 5.1_p16-r2 ld xtools-2.2.4 ld (Gentoo binutils-apple-8.2.1-r101) app-misc/pax-utils: 1.3.5::gentoo_prefix app-shells/bash: 5.1_p16-r2::gentoo_prefix dev-lang/perl: 5.36.0::gentoo_prefix dev-lang/python: 3.9.12::gentoo_prefix, 3.10.4::local dev-util/cmake: 3.24.1::gentoo_prefix dev-util/meson: 0.63.1::gentoo_prefix sys-apps/baselayout: 2.8-r2::gentoo_prefix sys-devel/autoconf: 2.71-r1::gentoo_prefix sys-devel/automake: 1.16.5::gentoo_prefix sys-devel/binutils-config: 5.1-r4::gentoo_prefix sys-devel/clang: 14.0.6-r1::gentoo_prefix sys-devel/gcc: 12.1.0::gentoo_prefix sys-devel/gcc-config: 1.9.1::gentoo_prefix sys-devel/libtool: 2.4.7::gentoo_prefix sys-devel/llvm: 14.0.6-r2::gentoo_prefix sys-devel/make: 4.3::gentoo_prefix Repositories: gentoo_prefix location: /Users/sam/Gentoo/var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.prefix.bitzolder.nl/gentoo-portage-prefix priority: -1000 aliases: gentoo sync-rsync-verify-jobs: 1 sync-rsync-verify-metamanifest: no sync-rsync-extra-opts: sync-rsync-verify-max-age: 24 local location: /Users/sam/Gentoo/var/db/repos/local masters: gentoo_prefix ACCEPT_KEYWORDS="~x64-macos" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-apple-darwin21" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-apple-darwin21" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/terminfo" CONFIG_SHELL="/Users/sam/Gentoo/bin/bash" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/Users/sam/Gentoo/var/cache/distfiles" EMERGE_DEFAULT_OPTS=" --keep-going --complete-graph" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY 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" 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 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" MAKEOPTS="-j4" PKGDIR="/Users/sam/Gentoo/var/cache/binpkgs" PORTAGE_CONFIGROOT="/Users/sam/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/sam/Gentoo/var/tmp" SHELL="/Users/sam/Gentoo/bin/zsh" USE="aqua coreaudio emacs ipv6 libglvnd ncurses objc objc++ prefix prefix-guest readline ssl x64-macos zlib" ABI_X86="64" ADA_TARGET="gnat_2020" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache 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_X86="mmx mmxext sse sse2" ELIBC="Darwin" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" INPUT_DEVICES="libinput" KERNEL="Darwin" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php7-4 php8-0" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_10" PYTHON_TARGETS="python3_10" RUBY_TARGETS="ruby27" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LANG, LC_ALL, LD, LEX, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
Created attachment 803248 [details] linker-detection-hack.patch
Eli Schwartz from Meson took a look and kindly explained the problem. Meson currently looks for 'PROJECT:ld64' in 'ld -v' output. This is what I get if I run the real ld64 from Apple outside of Prefix: ``` $ ld -v @(#)PROGRAM:ld PROJECT:ld64-764 BUILD 11:22:50 Apr 28 2022 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 13.1.6, (clang-1316.0.21.2.5) (static support for 28, runtime is 28) TAPI support using: Apple TAPI version 13.1.6 (tapi-1316.0.7.3) ``` But inside prefix, calling the CHOST-prefixed ld: ``` $ x86_64-apple-darwin21-ld --version xtools-2.2.4 ld (Gentoo binutils-apple-8.2.1-r101) Based on Apple Inc. ld64-274.2 configured to support archs: ppc ppc64 i386 x86_64 x86_64h armv6 armv6m armv7 armv7s armv7m armv7em arm64 TAPI support using: tapilite based on Apple TAPI version 1000.10.8 (https://github.com/grobian/darwin-xtools.git) ``` grobian: do you know if any Apple linkers ever lacked "PROJECT:ld64" in the first line? If so, we might be able to adjust Meson upstream. If not, we should consider just patching binutils-apple to include that in the first line. I've attached a hacky patch to meson for now but I don't really want to apply that.
I think in any case meson would be the first to look for PROJECT:ld64 (or PROJECT:ld) becase we've never seen any issue before :) That said, I think 274 and 764 are quite far apart. I cannot find it in older versions (https://github.com/apple-oss-distributions/ld64/tree/ld64-77.1/src) but I guess we can add this marker to the header somewhere, just for meson, and meson alone.
*** Bug 869617 has been marked as a duplicate of this bug. ***
How do I configure my incomplete installation of Prefix to add an overlay which would contain a modified ebuild using the hacky patch attached? I already know to edit an ebuild and make a local overlay. Speaking of incomplete, why emerge is no longer inside $EPREFIX ?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e87a1383004c856e74741f682c556bc3e8c67990 commit e87a1383004c856e74741f682c556bc3e8c67990 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2022-09-11 15:08:10 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2022-09-11 15:09:34 +0000 dev-util/meson-0.63.2-r1: teach meson to detect xtools linkers Unbreak x86_64 and ppc based darwin targets. Closes: https://bugs.gentoo.org/868516 Signed-off-by: Fabian Groffen <grobian@gentoo.org> .../meson/files/meson-0.63-xtools-support.patch | 26 ++++++++++++++++++++++ ...{meson-0.63.2.ebuild => meson-0.63.2-r1.ebuild} | 4 ++++ dev-util/meson/meson-9999.ebuild | 4 ++++ 3 files changed, 34 insertions(+)
Please submit the patch upstream.
Yeah so for the record (with my Meson dev hat on), I've had my eye on this bug report because I was waiting to see what grobian thought about the correct place for the fix. (I'm not terribly biased about whether xtools or Meson should be responsible for this. And I guess you all know more about Apple linkers than I do anyway...) Also I would be happy to review Meson patches to support Gentoo Prefix better, if you think this is better handled in Meson. I suspect I'm not the only one disappointed to see the conclusion be "I have a patch, but I'll just ninja patch it into some other maintainer's package where it can sit and gather dust until it no longer applies and gets dropped, rather than submit it upstream". Instead of inviting revert wars in Gentoo, I have to ask... why not just send me the patch for inclusion into upstream Meson? Is this really so hard?
(In reply to Larry the Git Cow from comment #8) > The bug has been closed via the following commit(s): I guess my first question in comment #7 is now obsolete. Now, can I resume the bootstrapping, and if so, how? Or do I have to start all over again (that would take two days or so on that 2015 MacBook Pro)?
(In reply to Eli Schwartz from comment #10) > Yeah so for the record (with my Meson dev hat on), I've had my eye on this > bug report because I was waiting to see what grobian thought about the > correct place for the fix. (I'm not terribly biased about whether xtools or > Meson should be responsible for this. And I guess you all know more about > Apple linkers than I do anyway...) > > Also I would be happy to review Meson patches to support Gentoo Prefix > better, if you think this is better handled in Meson. > > I suspect I'm not the only one disappointed to see the conclusion be "I have > a patch, but I'll just ninja patch it into some other maintainer's package > where it can sit and gather dust until it no longer applies and gets > dropped, rather than submit it upstream". > > Instead of inviting revert wars in Gentoo, I have to ask... why not just > send me the patch for inclusion into upstream Meson? Is this really so hard? You broke all users, I had 2 choices: make people re-install meson (a small package), or make people re-install their linker (a large package). Since meson is the first and only package every to complain about the linker, and since it is significantly smaller than just the linker, I "ninja patch"-ed meson. I simply care about users, and my own systems. I hope they are able to actually recover without manual steps, as I was on systems of my own. Thank you.
That doesn't explain why you couldn't speak to upstream and submit a patch there, even in parallel (you didn't necessarily have to wait for comment to then add it in Gentoo, although a short period would be polite): 1. They may have comments on the patch and deem it inappropriate, and suggest a better method; 2. This is now something that the meson maintainer has to carry forever if it's not been sent upstream. You now have someone from Meson actively telling you they are happy to help and your response is "you broke us"? That's not how we facilitate good relations with upstreams.
(In reply to René Rhéaume from comment #11) > (In reply to Larry the Git Cow from comment #8) > > The bug has been closed via the following commit(s): > I guess my first question in comment #7 is now obsolete. Now, can I resume > the bootstrapping, and if so, how? Or do I have to start all over again > (that would take two days or so on that 2015 MacBook Pro)? Hi René, you shouldn't have to. Here's what I think you should do: rm ${EPREFIX}/var/db/repos/gentoo/metadata/timestamp ./bootstrap-prefix <use the same $EPREFIX as you did the first time> This should re-sync the tree (getting a fixed meson), and re-start the merging process, hopefully upgrading meson here before trying pax-utils. Let me know if it doesn't.
(In reply to Sam James from comment #13) > That doesn't explain why you couldn't speak to upstream and submit a patch > there, even in parallel (you didn't necessarily have to wait for comment to > then add it in Gentoo, although a short period would be polite): > > 1. They may have comments on the patch and deem it inappropriate, and > suggest a better method; > > 2. This is now something that the meson maintainer has to carry forever if > it's not been sent upstream. > > You now have someone from Meson actively telling you they are happy to help > and your response is "you broke us"? That's not how we facilitate good > relations with upstreams. I don't recall saying I didn't want to bring this upstream. I just recall making an effor to unbreak user-systems, at my earliest convenience, inbetween various other things going on in my life. Thank you.
(In reply to Fabian Groffen from comment #15) > I don't recall saying I didn't want to bring this upstream. I just recall > making an effor to unbreak user-systems, at my earliest convenience, > inbetween various other things going on in my life. Thank you. In response to two people saying "please upstream", you just said "I prefer to keep systems working" and the bug remained closed until I reopened it. To many, that would appear as apathy or an intent not to. And again, the "you broke us" is antagonistic.
Ok, I can see now, that may have come off harsh. I'm sorry for that. I've filed an upstream issue. Do you want me to revert the commit I did in gx86? I can move it to the overlay instead.
(In reply to Fabian Groffen from comment #14) > Here's what I think you should do: > > rm ${EPREFIX}/var/db/repos/gentoo/metadata/timestamp > ./bootstrap-prefix > <use the same $EPREFIX as you did the first time> > > This should re-sync the tree (getting a fixed meson), and re-start the > merging process, hopefully upgrading meson here before trying pax-utils. > > Let me know if it doesn't. Unfortunately, this does not seem to re-sync the tree, only trying to resume the "emerge -e @system" command, because meson is not getting updated or rebuilt. At least, it won't trash about two days of CPU cycles right away. And this meson problem is also affecting dev-libs/jsoncpp-1.9.5 , which is the first ebuild of my resume list. The bootstrap-prefix.sh script wrote "emerge -v --resume" command failed.
(In reply to René Rhéaume from comment #18) > (In reply to Fabian Groffen from comment #14) > > Here's what I think you should do: > > > > rm ${EPREFIX}/var/db/repos/gentoo/metadata/timestamp > > ./bootstrap-prefix > > <use the same $EPREFIX as you did the first time> > > > > This should re-sync the tree (getting a fixed meson), and re-start the > > merging process, hopefully upgrading meson here before trying pax-utils. > > > > Let me know if it doesn't. > Unfortunately, this does not seem to re-sync the tree, only trying to resume > the "emerge -e @system" command, because meson is not getting updated or > rebuilt. At least, it won't trash about two days of CPU cycles right away. > And this meson problem is also affecting dev-libs/jsoncpp-1.9.5 , which is > the first ebuild of my resume list. The bootstrap-prefix.sh script wrote > "emerge -v --resume" command failed. Ok, this is a bit annoying, but you can try the following: $EPREFIX/bin/bash -l cd $EPREFIX/var/db/repos/gentoo/dev-util/meson curl "http://rsync.prefix.bitzolder.nl/dev-util/meson/meson-0.63.2-r1.ebuild" > meson-0.63.2-r1.ebuild mkdir files curl "http://rsync.prefix.bitzolder.nl/dev-util/meson/files/meson-0.63-xtools-support.patch" > files/meson-0.63-xtools-support.patch ebuild meson-0.63.2-r1.ebuild digest merge clean exit now this should download the new ebuild and its patch, and report something about Creating Manifest, and installing new meson. If it did, you can afterwards run bootstrap-prefix again, this should now move past pax-utils and other packages.
(In reply to Fabian Groffen from comment #19) > If it did, you can afterwards run bootstrap-prefix again, this should now > move past pax-utils and other packages. It worked, thanks.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9746e7f65aa3ed3fa59473159742902c2c8246c7 commit 9746e7f65aa3ed3fa59473159742902c2c8246c7 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2023-07-09 11:48:59 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2023-07-09 11:50:13 +0000 sys-devel/binutils-apple-8.2.1-r103: produce ld64 compatible output For meson, mimic ld64's output on -v so it detects xtools as ld64. Closes: https://bugs.gentoo.org/868516 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/binutils-apple/Manifest | 2 +- .../binutils-apple-8.2.1-r101.ebuild | 122 --------------------- ...102.ebuild => binutils-apple-8.2.1-r103.ebuild} | 0 3 files changed, 1 insertion(+), 123 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=791e631e0121da91676113928a3e4070453c2449 commit 791e631e0121da91676113928a3e4070453c2449 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-01-17 04:50:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-17 05:54:01 +0000 Revert "dev-util/meson-1.3.1: fix for Darwin with native linker again" This reverts commit b7035fb0da8ffcf1577b68d43f49511adee8237d. This patch was previously introduced for bug 868516, and hit pushback by multiple parties that wanted to see this discussed upstream. After some coaxing and arm-twisting, an upstream issue was finally opened (but no patch submitted). The patch in ::gentoo went stale, and got dropped. base-system@ is uninterested in maintaining this out of tree patch given the situation (and neither am I). After the ticket was opened upstream, it was retracted by the submitter: > I decided to fix the problem from out custom version of xtools's end. Now it's back as a local patch to dev-build/meson, where it's just going to bitrot another time? No explanation for why this is necessary, especially if xtools added compatible output. No attempt to submit a PR to meson. No bug link to cross-reference relevant bugs. Solve this by reducing the local-patches tech debt and punting on the issue, pending actual upstreaming. We can revisit backporting a patch if and when it will constitute a backport of a patch available in upstream git master. Bug: https://bugs.gentoo.org/868516 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> .../meson/files/meson-1.3.1-xtools-support.patch | 26 ---------------------- dev-build/meson/meson-1.3.1.ebuild | 1 - 2 files changed, 27 deletions(-)
It is unclear to me whether there is still an issue, given the last I heard it had been fixed in xtools. Meanwhile, the patch bitrotted and got removed -- the dev-build/meson maintainers haven't been maintaining this patch. It is still my opinion that this should be offered upstream. Although an upstream ticket was filed, no PR was filed (not even a patch! sorry, diffs don't count, those cannot be applied in git). I'm not saying this patch cannot be used, but I am going to say that I would really rather not have a patch, if that patch doesn't include "Bug: XXX" links, doesn't explain why previous solutions aren't sufficient, and has no story for how to get it upstreamed. I don't want to jump through hoops over this, neither to maintain ::gentoo patches nor to do all the work translating a code change into a mergeable upstream PR. The combination of factors here is, honestly, a bit disappointing.
It's not fixed in xtools, nor can it. meson calls --version first, and barks if it doesn't recognise what it sees. I have no idea (anymore) why there was even a remote thinking this could be worked around in the linker, while the problem is so obviously in meson. So without it, current state of meson is that it is just broken on macOS with xtools linker. I guess that's just what we have to accept then for Gentoo. Disappointing indeed. Looks to me meson devs were never really interested in fixing this, quoting numbers and how few usage it has. The requested PR from upstream was "for it to be its own class", which sounds to me like a lot more work than just a simple tag, as I did. So, it seems to me meson devs discarded my inline patch as unsuitable, and requested more work to that. If you believe this is not the case and that there is a solution here that would make meson work with xtools, I can try and see. But given the recent actions where macOS just got relentlessly broken (again), it seems as even from within Gentoo there is a strong incentive not to allow to fix this.
(In reply to Fabian Groffen from comment #24) > I have no idea (anymore) why > there was even a remote thinking this could be worked around in the linker, > while the problem is so obviously in meson. So my takeaway from this is that you didn't even test it. In that case how can I expect you to have tested the meson diff? How do I know what's been tested and what hasn't been tested? > Looks to me meson devs were never really interested in fixing this, quoting > numbers and how few usage it has. This is pretty standard FOSS! "Quoting numbers and how few usage it has" and telling you that you'll need to open the PR yourself instead of waiting for someone else to open the PR, is not even remotely the same as "no one uses this so we don't want to accept the change, closing as WONTFIX". > The requested PR from upstream was "for > it to be its own class", which sounds to me like a lot more work than just a > simple tag, as I did. So, it seems to me meson devs discarded my inline > patch as unsuitable, and requested more work to that. Okay so as a core developer of meson (unlike the reviewer, who has contributed quite a bit to meson but isn't a meson maintainer and does not have a commit bit) I can absolutely clarify this for you. In mesonbuild/linkers/linkers.py, the import location for the existing class that you repurposed, a bunch of common code exists (the "MixIn" programming pattern), which is used by various classes per compiler linker. Some of those classes are two lines, one to define a new class and one to set the unique id of the class (for example so that users can fetch the detected compiler id and distinguish between ld.bfd, ld.lld, ld64, and more). It's not a "lot of work" to implement this. But in the issue ticket you responded by saying that xtools is exactly the same as ld64 as far as the user is concerned, so it should never be necessary to distinguish between them -- fine, I accept that logic, you would know best. Consider that review comment successfully responded to, and don't bother with a new class. > If you believe this > is not the case and that there is a solution here that would make meson work > with xtools, I can try and see. But given the recent actions where macOS > just got relentlessly broken (again), it seems as even from within Gentoo > there is a strong incentive not to allow to fix this. If by "relentlessly broken" you mean meson, then I don't understand what you mean, because the only thing anyone has said in relation to meson is that we would like a serious effort to be made to have any changes ***merged upstream***. By serious effort made, I don't mean "inform meson about xtools and then expect them to do all the work".
Also you're the one that closed this bug (and the meson ticket) as "FIXED", quite some time ago. So for the sake of clarity it would be best if you don't do that unless you know it's fixed, or no one else is going to track that for you. If it isn't fixed, please reopen it. I can't tell if it's fixed due to the complete lack of communication or explanation involved in the commit to gentoo.git a few days ago.
(In reply to Eli Schwartz from comment #25) > (In reply to Fabian Groffen from comment #24) > > I have no idea (anymore) why > > there was even a remote thinking this could be worked around in the linker, > > while the problem is so obviously in meson. > > So my takeaway from this is that you didn't even test it. In that case how > can I expect you to have tested the meson diff? > > How do I know what's been tested and what hasn't been tested? What do you mean? meson doesn't work without the patch. I ran into the issue, after applying the patch I could move forward again. Did I break anything by adding the patch? I tested for that on a regular x64-linux box. > > Looks to me meson devs were never really interested in fixing this, quoting > > numbers and how few usage it has. > > This is pretty standard FOSS! "Quoting numbers and how few usage it has" and > telling you that you'll need to open the PR yourself instead of waiting for > someone else to open the PR, is not even remotely the same as "no one uses > this so we don't want to accept the change, closing as WONTFIX". Hmmm, certainly came across harsh to me. > > The requested PR from upstream was "for > > it to be its own class", which sounds to me like a lot more work than just a > > simple tag, as I did. So, it seems to me meson devs discarded my inline > > patch as unsuitable, and requested more work to that. > > Okay so as a core developer of meson (unlike the reviewer, who has > contributed quite a bit to meson but isn't a meson maintainer and does not > have a commit bit) I can absolutely clarify this for you. This was not clear to me. I assumed the person to have a say (even be a dev). My bad, I presume. > In mesonbuild/linkers/linkers.py, the import location for the existing class > that you repurposed, a bunch of common code exists (the "MixIn" programming > pattern), which is used by various classes per compiler linker. Some of > those classes are two lines, one to define a new class and one to set the > unique id of the class (for example so that users can fetch the detected > compiler id and distinguish between ld.bfd, ld.lld, ld64, and more). > > It's not a "lot of work" to implement this. But in the issue ticket you > responded by saying that xtools is exactly the same as ld64 as far as the > user is concerned, so it should never be necessary to distinguish between > them -- fine, I accept that logic, you would know best. Well -- and please understand I'm not unwilling here -- I don't understand exactly what you want me to do codewise at this point. Which is basically why I opened the bug with a rough patch, to get some idea of what it would take. My impression was the patch wasn't sufficient, but I didn't get a feel for what I would have to do to make a PR that would be more acceptable. > Consider that review comment successfully responded to, and don't bother > with a new class. If you're upstream, then you're the one to have a big say in how it should look like if you're going to support it. So my hacky fix in that isn't of any measure. I suppose you know the code and its intended structure, I don't. That said, indeed xtools is just an ld64 "fork" if you want, but it (for reasoning which are GNU) accepts --version. GCC knows very well how to operate with xtools (because it's like ld64). > > If you believe this > > is not the case and that there is a solution here that would make meson work > > with xtools, I can try and see. But given the recent actions where macOS > > just got relentlessly broken (again), it seems as even from within Gentoo > > there is a strong incentive not to allow to fix this. > > If by "relentlessly broken" you mean meson, then I don't understand what you > mean, because the only thing anyone has said in relation to meson is that we > would like a serious effort to be made to have any changes ***merged > upstream***. Right. I mean any user of macOS using x64 or ppc. Because meson unfortunately is a package that needs to work if you want to have a working system. So I do not really have the luxury to wait. I need to be able to compile (system) packages. I can understand this is of a lesser concern for meson itself. > By serious effort made, I don't mean "inform meson about xtools and then > expect them to do all the work". Well, in my experience there usually is something inbetween. (In reply to Eli Schwartz from comment #26) > Also you're the one that closed this bug (and the meson ticket) as "FIXED", > quite some time ago. Yup, I was apparently under the false impression I could fix it from xtools' side. > So for the sake of clarity it would be best if you don't do that unless you > know it's fixed, or no one else is going to track that for you. This is sub-optimal, I agree, because the issue still is standing. > If it isn't fixed, please reopen it. I can't tell if it's fixed due to the > complete lack of communication or explanation involved in the commit to > gentoo.git a few days ago. Well, ok, to make sure there is no room for unclarity here: meson with xtools linker is completely broken
Patch merged upstream. Thanks, I appreciate your willingness to help get this sorted out. :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e538accf3e4cb33b8537290de31ce4fc503047c8 commit e538accf3e4cb33b8537290de31ce4fc503047c8 Author: Eli Schwartz <eschwartz93@gmail.com> AuthorDate: 2024-01-18 20:26:51 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-18 20:43:22 +0000 dev-build/meson: backport macos Prefix fix Followup to commit 791e631e0121da91676113928a3e4070453c2449. The patch has been integrated upstream and will be backported to meson 1.3.2; the issues with including it here have been resolved, so bring it back. Closes: https://bugs.gentoo.org/868516 Signed-off-by: Eli Schwartz <eschwartz93@gmail.com> Signed-off-by: Sam James <sam@gentoo.org> .../meson/files/meson-1.3.1-xtools-support.patch | 39 ++++++++++++++++++++++ .../{meson-1.3.1.ebuild => meson-1.3.1-r1.ebuild} | 3 ++ 2 files changed, 42 insertions(+)
Thanks!
For purposes of documentation: what I did back when I thought I could fix this in xtools was https://github.com/grobian/darwin-xtools/commit/37f08761f6e7bed7b531882ed71e24521bf8e8cf. E.g. calling xtools' ld64 -v will emit compatible output. However, since meson first calls --version, we never got to benefit from this.
