Created attachment 674392 [details] build.log xcode-select: Failed to locate 'x86_64-apple-darwin18-ar', requesting installation of command line developer tools. make[2]: *** [Makefile:477: libmpn.la] Error 72 make[2]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/dev-libs/gmp-6.2.1/work/gmp-6.2.1-abi_x86_64.amd64/mpn' make[1]: *** [Makefile:997: all-recursive] Error 1 make[1]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/dev-libs/gmp-6.2.1/work/gmp-6.2.1-abi_x86_64.amd64' make: *** [Makefile:787: all] Error 2 * ERROR: dev-libs/gmp-6.2.1::gentoo_prefix failed (compile phase): * emake failed
I think this is a combination of using a profile w/ CHOST darwin18, which is fine, but having a newer installation of xcode CLI tools which doesn't have the expected binary versioning. I'll try install an older CLI tools but I guess I need to try bump the headers and create a newer profile to mess with.
(In reply to Sam James from comment #1) > I think this is a combination of using a profile w/ CHOST darwin18, which is > fine, but having a newer installation of xcode CLI tools which doesn't have > the expected binary versioning. > > I'll try install an older CLI tools but I guess I need to try bump the > headers and create a newer profile to mess with. I can't get an older CLI tools package installed on Big Sur so I guess it's the messy route, or symlinks.
(In reply to Sam James from comment #2) > (In reply to Sam James from comment #1) > > I think this is a combination of using a profile w/ CHOST darwin18, which is > > fine, but having a newer installation of xcode CLI tools which doesn't have > > the expected binary versioning. > > > > I'll try install an older CLI tools but I guess I need to try bump the > > headers and create a newer profile to mess with. > > I can't get an older CLI tools package installed on Big Sur so I guess it's > the messy route, or symlinks. OK. So: * ${EPREFIX}/tmp/usr/x86_64-apple-darwin19/binutils-bin/native-4/ar and such are all fine * but ${EPREFIX}/tmp/usr/bin/x86_64-* are all pointing to... lrwxr-xr-x 1 sam staff 54 Nov 23 01:17 x86_64-apple-darwin19-ar -> /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin19/bin/ar lrwxr-xr-x 1 sam staff 54 Nov 23 01:17 x86_64-apple-darwin19-as -> /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin19/bin/as lrwxr-xr-x 1 sam staff 59 Nov 23 01:17 x86_64-apple-darwin19-c++filt -> /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin19/bin/c++filt lrwxr-xr-x 1 sam staff 69 Nov 23 01:17 x86_64-apple-darwin19-install_name_tool -> /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin19/bin/install_name_tool .. which, when called, give that irritating message. I don't know why those binaries don't call the 'ar' which is installed by xcode. They seem to be trying the wrong path / linking to the wrong place as 'ar' exists fine. Deleting those symlinks for now allows gmp to build anyway.
gmp is calling most likely ar, which gets mapped onto ${CHOST}-ar (binutils-config), which is symlinked to /usr/bin/ar (native-cctools -- path taken I think?), which believes it is called as ${CHOST}-ar, and tries to lookup that tool. So, either, a) fix the CHOST (just introduce the missing profile(s) in the tree), or b) use wrapper scripts with native-cctools instead of symlinks, such that argv[0] is set to ar/ld/etc and not whatever we called the symlink. I think b) is a safer choice in any case not to break a prefix instantly the host gets upgraded + Xcode. a) we probably should do rather sooner than later, but I stopped doing it because at some point I thought it would be a good idea to provide headers ourselves and we'd be stuck at the latest being released by Apple (= stuck CHOST), but since this was a dead-end, we should now just add all profiles (a)).
(In reply to Fabian Groffen from comment #4) > gmp is calling most likely ar, which gets mapped onto ${CHOST}-ar > (binutils-config), which is symlinked to /usr/bin/ar (native-cctools -- path > taken I think?), which believes it is called as ${CHOST}-ar, and tries to > lookup that tool. > > So, either, a) fix the CHOST (just introduce the missing profile(s) in the > tree), or b) use wrapper scripts with native-cctools instead of symlinks, > such that argv[0] is set to ar/ld/etc and not whatever we called the symlink. > > I think b) is a safer choice in any case not to break a prefix instantly the > host gets upgraded + Xcode. a) we probably should do rather sooner than > later, but I stopped doing it because at some point I thought it would be a > good idea to provide headers ourselves and we'd be stuck at the latest being > released by Apple (= stuck CHOST), but since this was a dead-end, we should > now just add all profiles (a)). So, this makes complete sense, but I actually still get: >xcode-select: Failed to locate 'x86_64-apple-darwin20-ar', requesting installation of command line developer tools. with the latest rsync snapshot (probably a few hours old, but enough to get the 11.0 profiles). I can't actually find anything like x86_64-apple-darwin20-ar on my system. Calling `ar` within the prefix itself works: $ Gentoo/tmp/usr/bin/ar usage: ar -d [-TLsv] archive file ... ar -m [-TLsv] archive file ... ar -m [-abiTLsv] position archive file ... ar -p [-TLsv] archive [file ...] ar -q [-cTLsv] archive file ... ar -r [-cuTLsv] archive file ... ar -r [-abciuTLsv] position archive file ... ar -t [-TLsv] archive [file ...] ar -x [-ouTLsv] archive [file ...] But I guess this doesn't help if it's invoked as x86_64-apple-darwin20-ar. So, I guess my real question is, why doesn't it pick up the 'ar' on the system?
Actually, this gets interesting, because ar == libtool. (and on Darwin, libtool != glibtool) So, the question really is, ar is provided by what, and why isn't there a CHOST-ar created? If its, what does it point to? It could very well be, that ar/libtool checks how it is called, and thinks that CHOST-ar != ar, thus libtool. Or something. But I cannot explain why it would then think it wants to install command line tools.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ddd1c8bdca710a247562f2a25c82f61f14733054 commit ddd1c8bdca710a247562f2a25c82f61f14733054 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-11-26 16:46:40 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-11-26 16:46:47 +0000 sys-devel/native-cctools-5: version bump for macOS Big Sur Closes: https://bugs.gentoo.org/756157 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/native-cctools/native-cctools-5.ebuild | 119 +++++++++++++++++++++++ 1 file changed, 119 insertions(+)
