Created attachment 684846 [details] gcc build.log compressed with xz On my Mac OS X 10.15 Catalina AMD64 system, sys-devel/gcc-10.2.0-r5 in the emerge -e @system stage fails, with an error saying: ld: library not found for -ldylib1.o while linking libgcc.a. The full error message leading up to this is: # /opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/xgcc -B/opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/ -B/opt/gentoo/usr/x86_64-apple-darwin19/bin/ -B/opt/gentoo/usr/x86_64-apple-darwin19/lib/ -isystem /opt/gentoo/usr/x86_64-apple-darwin19/include -isystem /opt/gentoo/usr/x86_64-apple-darwin19/sys-include -fno-checking and -O2 -g -pipe -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -mmacosx-version-min=10.4 -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-stack-clash-protection directly. # @multilib_dir@ is not really necessary, but sometimes it has # more uses than just a directory name. /opt/gentoo/bin/bash /opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/gcc-10.2.0/libgcc/../mkinstalldirs . /opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/xgcc -B/opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/./gcc/ -B/opt/gentoo/usr/x86_64-apple-darwin19/bin/ -B/opt/gentoo/usr/x86_64-apple-darwin19/lib/ -isystem /opt/gentoo/usr/x86_64-apple-darwin19/include -isystem /opt/gentoo/usr/x86_64-apple-darwin19/sys-include -fno-checking -O2 -g -pipe -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wno-error=format-diag -Wold-style-definition -isystem ./include -mmacosx-version-min=10.4 -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-stack-clash-protection -dynamiclib -nodefaultlibs -install_name /opt/gentoo/usr/lib/gcc/x86_64-apple-darwin19/10.2.0/libgcc_s.1.dylib -single_module -o ./libgcc_s.dylib -Wl,-exported_symbols_list,libgcc.map -compatibility_version 1 -current_version 1.0 -g -pipe -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulhc3_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divhc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _fixsfti_s.o _fixdfti_s.o _fixxfti_s.o _fixtfti_s.o _fixunssfti_s.o _fixunsdfti_s.o _fixunsxfti_s.o _fixunstfti_s.o _floattisf_s.o _floattidf_s.o _floattixf_s.o _floattitf_s.o _floatuntisf_s.o _floatuntidf_s.o _floatuntixf_s.o _floatuntitf_s.o _divdi3_s.o _moddi3_s.o _divmoddi4_s.o _udivdi3_s.o _umoddi3_s.o _udivmoddi4_s.o _udiv_w_sdiv_s.o darwin-64_s.o cpuinfo_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o fixtfti_s.o fixunstfti_s.o floattitf_s.o floatuntitf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-darwin_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc ld: library not found for -ldylib1.o collect2: error: ld returned 1 exit status make[3]: *** [Makefile:994: libgcc_s.dylib] Error 1 make[3]: Leaving directory '/opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build/x86_64-apple-darwin19/libgcc' make[2]: *** [Makefile:16386: all-stage1-target-libgcc] Error 2 make[2]: Leaving directory '/opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build' make[1]: *** [Makefile:21684: stage1-bubble] Error 2 make[1]: Leaving directory '/opt/gentoo/var/tmp/portage/sys-devel/gcc-10.2.0-r5/work/build' make: *** [Makefile:22000: bootstrap-lean] Error 2 * ERROR: sys-devel/gcc-10.2.0-r5::gentoo_prefix failed (compile phase): * emake failed * and then so forth with the Gentoo error. Things I have tried: - MacPorts is installed, I have removed it from the PATH. - Completely fresh bootstrap twice. - Resuming using a single core. I have attached: - gcc-build-logs.tar.bz2 - the complete build log (build.log) - the ebuild environment file (environemnt)
Created attachment 684849 [details] gcc-build-logs.tar.bz2 as per emerge asking me to
Created attachment 684852 [details] environment file from emerge
odd, is there anything special about your machine/install? Can you check your stage3.log that sys-devel/gcc-10.2.0-r5 was used there?
(In reply to Fabian Groffen from comment #3) > odd, is there anything special about your machine/install? Not particularly, apart from the use of MacPorts, which I believe has been removed from the environment for this prefix bootstrap. > Can you check your stage3.log that sys-devel/gcc-10.2.0-r5 was used there? Well, this build I am referencing that is failing is not in stage3.log (I think that is what is meant to happen, no?) and sys-devel/gcc-10.2.0-r5 was emerge'd there... eselect gcc list shows only: [1] x86_64-apple-darwin19-10.2.0 so I believe it is being used. If it matters, the profile being used is gentoo_prefix:prefix/darwin/macos/10.15/x64/gcc. stage3.log is also attached now, as I am unsure if I am even gleaning the right information from the log.
Created attachment 684855 [details] stage3.log Repo sync truncated to reduce log file size below 1M.
I wanted to assure that it built the exact same compiler before. Can you run from your prefix: qlop -uUsv I wonder if something was depcleaned that is necessary in your case.
and the output from readlink $EPREFIX/MacOSX.sdk
qlop -uUsv: 2021-01-27T14:14:40 *** gentoo_prefix 2021-01-27T14:45:30 <<< sys-devel/native-cctools-5 2021-01-27T14:50:09 <<< sys-libs/ncurses-6.2-r1 2021-01-27T14:50:21 <<< app-arch/bzip2-1.0.8-r1 2021-01-27T14:50:27 <<< sys-devel/gnuconfig-20210107 2021-01-27T14:50:31 <<< sys-apps/gentoo-functions-0.14 2021-01-27T14:50:35 <<< virtual/libcrypt-1-r1 2021-01-27T14:50:41 <<< app-misc/c_rehash-1.7-r1 2021-01-27T14:50:45 <<< acct-group/sshd-0-r1 2021-01-27T14:52:12 <<< sys-devel/patch-2.7.6-r4 2021-01-27T14:53:07 <<< app-arch/gzip-1.10 2021-01-27T14:53:11 <<< virtual/os-headers-0-r2 2021-01-27T14:53:33 <<< dev-libs/libffi-3.3-r2 2021-01-27T14:53:37 <<< app-misc/mime-types-9 2021-01-27T14:53:41 <<< app-misc/editor-wrapper-4-r1 2021-01-27T14:54:38 <<< app-misc/pax-utils-1.2.8 2021-01-27T14:54:44 <<< sys-apps/baselayout-prefix-2.6-r2 2021-01-27T14:54:58 <<< sys-apps/which-2.21 2021-01-27T14:55:02 <<< sys-process/pkill-darwin-1.0 2021-01-27T14:55:06 <<< virtual/libc-1-r1 2021-01-27T14:55:10 <<< sys-devel/automake-wrapper-11 2021-01-27T14:55:14 <<< sys-devel/autoconf-wrapper-13-r1 2021-01-27T14:56:23 <<< dev-util/re2c-2.0.3 2021-01-27T14:56:44 <<< dev-util/pkgconf-1.7.3-r1 2021-01-27T14:57:05 <<< sys-apps/less-563-r1 2021-01-27T14:57:09 <<< sys-devel/gcc-config-1.9.1 2021-01-27T14:57:17 <<< sys-devel/binutils-config-5.1-r4 2021-01-27T14:57:23 <<< acct-user/sshd-0-r1 2021-01-27T14:57:34 <<< sys-apps/darwin-miscutils-12 2021-01-27T14:57:38 <<< virtual/pkgconfig-2 2021-01-27T14:58:10 <<< sys-libs/readline-8.1 2021-01-27T14:58:14 <<< virtual/pager-0 2021-01-27T14:58:48 <<< net-libs/nghttp2-1.42.0 2021-01-27T14:59:02 <<< dev-lang/python-exec-2.4.6-r3 2021-01-27T14:59:46 <<< app-arch/xz-utils-5.2.5 2021-01-27T14:59:52 <<< app-portage/elt-patches-20201205 2021-01-27T15:00:04 <<< sys-libs/zlib-1.2.11-r3 2021-01-27T15:01:16 <<< dev-libs/libiconv-1.15 2021-01-27T15:02:36 <<< app-arch/zstd-1.4.8-r1 2021-01-27T15:04:08 <<< sys-devel/m4-1.4.18-r1 2021-01-27T15:08:04 <<< dev-libs/libltdl-2.4.6 2021-01-27T15:08:08 <<< dev-util/gtk-doc-am-1.33.1 2021-01-27T15:10:08 <<< dev-libs/gmp-6.2.1 2021-01-27T15:10:13 <<< virtual/libiconv-0-r2 2021-01-27T15:10:49 <<< sys-apps/file-5.39-r3 2021-01-27T15:11:52 <<< dev-libs/mpfr-4.1.0 2021-01-27T15:13:22 <<< dev-libs/libintl-0.21 2021-01-27T15:13:29 <<< virtual/libintl-0-r2 2021-01-27T15:13:54 <<< dev-libs/mpc-1.2.1 2021-01-27T15:15:29 <<< app-shells/bash-5.1_p4 2021-01-27T15:19:21 <<< sys-apps/coreutils-8.32 2021-01-27T15:25:05 <<< dev-lang/perl-5.32.0-r1 2021-01-27T15:25:29 <<< sys-devel/autoconf-2.69-r5 2021-01-27T15:25:33 <<< virtual/perl-Data-Dumper-2.174.0-r1 2021-01-27T15:25:37 <<< virtual/perl-Test-Harness-3.420.0-r3 2021-01-27T15:25:46 <<< perl-core/File-Temp-0.230.900 2021-01-27T15:25:55 <<< virtual/perl-File-Temp-0.230.900 2021-01-27T15:30:55 <<< dev-libs/openssl-1.1.1i 2021-01-27T15:31:25 <<< dev-util/meson-format-array-0 2021-01-27T15:31:35 <<< app-admin/eselect-1.4.17 2021-01-27T15:33:02 <<< app-arch/libarchive-3.5.1 2021-01-27T15:35:10 <<< app-arch/tar-1.33 2021-01-27T15:35:34 <<< app-arch/xar-1.8-r4 2021-01-27T15:36:19 <<< app-crypt/rhash-1.4.1 2021-01-27T15:37:29 <<< app-editors/nano-5.5 2021-01-27T15:37:33 <<< virtual/editor-0-r3 2021-01-27T15:37:57 <<< app-misc/ca-certificates-20200601.3.60 2021-01-27T15:38:55 <<< dev-libs/expat-2.2.10 2021-01-27T15:43:07 <<< dev-lang/python-3.8.7 2021-01-27T15:44:00 <<< dev-util/ninja-1.10.2-r1 2021-01-27T15:44:11 <<< dev-python/certifi-10001-r1 2021-01-27T15:44:25 <<< dev-python/setuptools-51.3.3 2021-01-27T15:44:42 <<< dev-util/meson-0.56.2 2021-01-27T15:44:55 <<< dev-python/setuptools_scm-5.0.1 2021-01-27T15:45:11 <<< dev-libs/jsoncpp-1.9.4 2021-01-27T15:49:17 <<< dev-libs/libuv-1.40.0 2021-01-27T15:50:58 <<< dev-libs/libxml2-2.9.10-r4 2021-01-27T15:59:50 <<< sys-devel/gettext-0.21 2021-01-27T16:01:28 <<< sys-apps/sed-4.8 2021-01-27T16:02:17 <<< sys-devel/make-4.3 2021-01-27T16:02:48 <<< dev-libs/popt-1.18 2021-01-27T16:05:14 <<< sys-apps/findutils-4.7.0 2021-01-27T16:09:06 <<< net-misc/wget-1.21-r1 2021-01-27T16:10:34 <<< sys-apps/diffutils-3.7-r1 2021-01-27T16:12:20 <<< sys-apps/grep-3.6 2021-01-27T16:13:10 <<< sys-devel/flex-2.6.4-r1 2021-01-27T16:16:13 <<< net-misc/rsync-3.2.3-r1 2021-01-27T16:18:28 <<< sys-apps/help2man-1.47.16 2021-01-27T16:19:08 <<< sys-apps/portage-3.0.12.0.2 2021-01-27T16:20:26 <<< sys-apps/gawk-5.1.0 2021-01-27T16:20:51 <<< sys-devel/automake-1.16.3-r1 2021-01-27T16:22:28 <<< virtual/package-manager-1 2021-01-27T16:23:31 <<< sys-devel/libtool-2.4.6-r6 2021-01-27T16:24:57 <<< sys-apps/debianutils-4.11.2 2021-01-27T16:25:27 <<< dev-libs/libyaml-0.2.5 2021-01-27T16:28:03 <<< net-misc/openssh-8.4_p1-r3 2021-01-27T16:30:44 <<< net-misc/curl-7.74.0-r2 2021-01-27T16:32:30 <<< virtual/ssh-0 2021-01-27T16:40:05 <<< dev-util/cmake-3.19.3 2021-01-27T16:49:36 <<< app-portage/portage-utils-0.90.1 2021-01-27T16:49:41 <<< app-admin/perl-cleaner-2.28 2021-01-27T16:51:51 <<< sys-devel/binutils-apple-8.2.1-r101 readlink $EPREFIX/MacOSX.sdk: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.0.sdk (uh, that looks wrong, what's an 11.0 sdk doing on a 10.15 system, but what do I know)
do you have /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk? Can you start with first changing the MacOSX.sdk symlink to the 10.15 SDK? That should work, else install the command line tools sdk, that one matches the host better. Perhaps we should encourage/require the use of commandlinetools for Prefix bootstraps if switching to it makes this works.
(In reply to Fabian Groffen from comment #9) > do you have /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk? > > Can you start with first changing the MacOSX.sdk symlink to the 10.15 SDK? > That should work, else install the command line tools sdk, that one matches > the host better. > > Perhaps we should encourage/require the use of commandlinetools for Prefix > bootstraps if switching to it makes this works. For some reason, I don't have the 10.15 (normal) SDK installed. However, I do have the 10.15 command line tools SDK installed, tried that from a fresh bootstrap and it failed :(
so, you made the commandlinetools the default sdk? as in, what `xcrun --show-sdk-path --sdk macosx` would return? That's what the symlink ends up pointing to.
if that's all setup, then I really don't see why I can't reproduce this, but I bet that -mmacos-version-min=10.4 is the culprit. GCC hardcodes that, but we could up it to 10.5 for all our targets are ... per host we don't even build for older targets so we could simply use the current version, but IIRC this broke other things within GCC itself. https://stackoverflow.com/questions/52211390/trouble-building-gcc-on-mac-cant-find-system-headers
in a failed bootstrap, can you enter it (env -i USER=$USER TERM=$TERM SHELL=$EPREFIX/bin/bash $EPREFIX/bin/bash -l) and emerge -1 native-cctools (you might have to unmask it via $EPREFIX/etc/portage/package.unmask) switch to it using binutils-config <id>, and then resume the gcc merge (emerge --resume). I wonder if somehow the linker responds differently here for you.
(In reply to Fabian Groffen from comment #11) > so, you made the commandlinetools the default sdk? as in, what `xcrun > --show-sdk-path --sdk macosx` would return? That's what the symlink ends up > pointing to. I forced the script (went in and edited the script) to use the commandlinetools sdk (hardcoded the path). (In reply to Fabian Groffen from comment #13) > in a failed bootstrap, can you enter it (env -i USER=$USER TERM=$TERM > SHELL=$EPREFIX/bin/bash $EPREFIX/bin/bash -l) and emerge -1 native-cctools > (you might have to unmask it via $EPREFIX/etc/portage/package.unmask) switch > to it using binutils-config <id>, and then resume the gcc merge (emerge > --resume). I wonder if somehow the linker responds differently here for you. Yeah, I can try that. Sorry that it's taking me some time to respond, this machine is often busy with other things, so sometimes it takes me a few days to test things :|
no problem, I'm more than happy that you want to try some things out, given that I cannot reproduce this
I see that there are Xcode and CommandLineTools updates, what Xcode do you have installed? Is this an Intel or M1 device?
I don't have the (In reply to Fabian Groffen from comment #16) > I see that there are Xcode and CommandLineTools updates, what Xcode do you > have installed? Is this an Intel or M1 device? This is an Intel device (it's running 10.15). Xcode 12.2, I can't figure out how to get the commandlinetools version... there's an update available, maybe I should test with that?
(In reply to Fabian Groffen from comment #13) > in a failed bootstrap, can you enter it (env -i USER=$USER TERM=$TERM > SHELL=$EPREFIX/bin/bash $EPREFIX/bin/bash -l) and emerge -1 native-cctools > (you might have to unmask it via $EPREFIX/etc/portage/package.unmask) switch > to it using binutils-config <id>, and then resume the gcc merge (emerge > --resume). I wonder if somehow the linker responds differently here for you. I have some good news now! I can confirm that this process you have specified works.
Although, I don't really want to be running my production prefix with that do I? I am more than happy to continue testing things so we can get this 'properly' fixed.
native-cctools simply relies on /usr/bin/ld instead of the ld we built ourselves. The crux here seems to be that -mmacosx-version-min=10.4 frustrates the linker; it believes it needs to pull in dylib1.o. ld: library not found for -ldylib1.o I think this is simply ignored by Apple's linker, and I think I can patch our linker to do the same, 10.4 is simply VERY old, and no longer supported on Intel.
Yeah, right, that makes sense. dylib1.o *does* exist (but only in the commandlinetools sdk) at /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.o. So I don't know why it's not being picked up when the commandlinetools sdk is being used. Regardless, it doesn't exist in the normal xcode SDK, so I agree that the linker should be patched.
Which SDKs do you have in here: /Library/Developer/CommandLineTools/SDKs/ For me: ls /Library/Developer/CommandLineTools/SDKs/*/usr/lib/dylib1.o /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/dylib1.o /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.o /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/lib/dylib1.o
Similar, do you have 10.5 dylib1? % ls /Library/Developer/CommandLineTools/SDKs/*/usr/lib/dylib1.*.o /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/dylib1.10.5.o /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.10.5.o /Library/Developer/CommandLineTools/SDKs/MacOSX11.1.sdk/usr/lib/dylib1.10.5.o There a couple of approaches to be taken from here. 1. patch gcc to target 10.5 as minimal target (opposed to 10.4), I think gcc upstream will start doing thing if Apple really removed dylib1.o 2. patch ld to ignore min-version 10.4 and up it to 10.5 transparently Ok, let's have a go at 2. Can you try and complete the bootstrap with native-cctools activated, then it's easy to update binutils-apple to a patched version, and try to recompile gcc after that.
Ok, I was wrong, it's cc1 of course that generates the dylib1.o reference, the linker doesn't do that. So the question now is how /usr/bin/ld masks that.
*** Bug 770133 has been marked as a duplicate of this bug. ***
My SDKs and dylib1: % ls -1 /Library/Developer/CommandLineTools/SDKs/*/usr/lib/dylib1.*.o /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/dylib1.10.5.o /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.10.5.o /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib/dylib1.10.5.o (identical for dylib1.o) Let me know if there is anything further I can do to assist you or attempt a solution :)
(In reply to fosslinux from comment #26) > My SDKs and dylib1: > > % ls -1 /Library/Developer/CommandLineTools/SDKs/*/usr/lib/dylib1.*.o > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/dylib1.10.5.o > /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib/dylib1.10.5. > o > /Library/Developer/CommandLineTools/SDKs/MacOSX11.0.sdk/usr/lib/dylib1.10.5.o > > (identical for dylib1.o) > > Let me know if there is anything further I can do to assist you or attempt a > solution :) What about the cctools bit?
(In reply to Sam James from comment #27) > What about the cctools bit? What about it? I currently have my Prefix completely bootstrapped with native-cctools, using the method described in comment #13. > easy to update binutils-apple to a patched version, and try to recompile gcc after that. RE: this bit, I don't believe such a patch yet exists (I could be wrong though)
Ok https://bootstrap.prefix.bitzolder.nl/results/x86_64-apple-darwin20/20210213/ This is the result of a bootstrap on a virgin BigSur 11.2.1. All I did? % xcode-select --install % ./bootstrap-prefix.sh In other words, there must be something different on the systems you two use. Yet, I'm clueless as to what it could be.
(In reply to Fabian Groffen from comment #29) > Ok > > https://bootstrap.prefix.bitzolder.nl/results/x86_64-apple-darwin20/20210213/ > > This is the result of a bootstrap on a virgin BigSur 11.2.1. All I did? > > % xcode-select --install > % ./bootstrap-prefix.sh > > In other words, there must be something different on the systems you two > use. Yet, I'm clueless as to what it could be. I'm still on Catalina. I wonder if that plays a role. Xcode 12.3.
(In reply to Göktürk Yüksek from comment #30) > (In reply to Fabian Groffen from comment #29) > > Ok > > > > https://bootstrap.prefix.bitzolder.nl/results/x86_64-apple-darwin20/20210213/ > > > > This is the result of a bootstrap on a virgin BigSur 11.2.1. All I did? > > > > % xcode-select --install > > % ./bootstrap-prefix.sh > > > > In other words, there must be something different on the systems you two > > use. Yet, I'm clueless as to what it could be. > > I'm still on Catalina. I wonder if that plays a role. Xcode 12.3. Ditto, same, I am on Catalina, Xcode 12.2
right, need to get onto that platform to see what's going on
Ok, I can reproduce this, bumping the macosxmin target from 10.4 to 10.6 makes the link succeed, I'm trying to figure out why (and in particular why this isn't a problem on 11.0)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=f0a132d3a17ee1ab20d135e8e99ea691ad50e536 commit f0a132d3a17ee1ab20d135e8e99ea691ad50e536 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2021-02-20 14:13:18 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2021-02-20 14:13:18 +0000 sys-devel/gcc-10.2.0-r5: fix build on darwin19 (10.15) For some reason on Catalina (10.15) the build fails with binutils-apple on not finding dylib1.o. The same problem doesn't exist on 10.13, nor 11.0, so simply up the minimum macOS version from 10.4 to 10.6 where dylib1.o is included in libSystem. Closes: https://bugs.gentoo.org/767415 Package-Manager: Portage-3.0.14-prefix, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/gcc/gcc-10.2.0-r5.ebuild | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
Sync in an hour or so, set binutils-apple as linker again and re-emerge gcc, that should do it.
confirmed by https://bootstrap.prefix.bitzolder.nl/results/x86_64-apple-darwin19/20210220
Fix confirmed here, full e2e bootstrap: Woah! Everything just worked! Now YOU should run /opt/gentoo/startprefix and enjoy! Thanks for using me, it was a pleasure to work with you. Thank you very much for your help, Fabian!
I can confirm that re-emerging gcc without the native-cctools works after the sync. Thanks for the fix.
