| Summary: | sys-devel/gcc-10.1.0-r1: failed build on macOS Big Sur (ld: library not found for -lc) | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Sam James <sam> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 755644 | ||
| Attachments: |
attempt 2: build.log snippet
Failing command with -v appended gcc-10.1.0-macos-slibgcc-undefined-libtool.patch |
||
|
Description
Sam James
2020-11-23 02:24:34 UTC
Created attachment 674719 [details]
attempt 2: build.log snippet
Unfortunately, it imploded again. That run was where I forced CC=clang, CXX=clang++ rather than implicit gcc/g++ being clang/clang++ respectively but it didn't make any difference (as expected :/).
I'll upload the full log with normal CC/CXX again shortly.
(In reply to Sam James from comment #1) > Created attachment 674719 [details] > attempt 2: build.log snippet > > Unfortunately, it imploded again. That run was where I forced CC=clang, > CXX=clang++ rather than implicit gcc/g++ being clang/clang++ respectively > but it didn't make any difference (as expected :/). > > I'll upload the full log with normal CC/CXX again shortly. I am wondering whether some of it is related to the flags being stripped out (until I change the eclass) and whether I need to be injecting something more. Here it is: https://dev.gentoo.org/~sam/tmp/gcc-10.1.0-r1-2020-11-24.build.log.xz I went digging and macports have a patch involving undefined symbols, so I'll try that: https://github.com/macports/macports-ports/commit/53ad57cd08c5971b5a92df34d84e62589bc006b4 - see https://trac.macports.org/ticket/60908#comment:5. (In reply to Sam James from comment #2) > I went digging and macports have a patch involving undefined symbols, so > I'll try that: > https://github.com/macports/macports-ports/commit/ > 53ad57cd08c5971b5a92df34d84e62589bc006b4 - see > https://trac.macports.org/ticket/60908#comment:5. The patch just gets me back to my original problem: >ld: library not found for -lc Log: https://dev.gentoo.org/~sam/tmp/gcc-10.1.0-r1-2020-11-24-2.build.log.xz So, I'm once again a bit stuck. I don't really know what to mess with from here. ok, the patch is fine, let's add it to the ebuild, and/or incorporate it in the other bigsur patch. Now, just -lc problems, that's an easy fix! Just symlink libc.dylib to libSystem.dylib. In fact, you can just do that in your prefix, thus $EPREFIX/usr/lib/libc.dylib -> /usr/lib/libSystem.dylib. Same trick you can repeat for libm if that exhibits the same problem. If that works, we can consider just adding those backwards compatibility symlinks, because they won't hurt anyone. Created attachment 674746 [details] Failing command with -v appended (In reply to Fabian Groffen from comment #4) > ok, the patch is fine, let's add it to the ebuild, and/or incorporate it in > the other bigsur patch. Nice! > > Now, just -lc problems, that's an easy fix! Just symlink libc.dylib to > libSystem.dylib. In fact, you can just do that in your prefix, thus > $EPREFIX/usr/lib/libc.dylib -> /usr/lib/libSystem.dylib. Same trick you can > repeat for libm if that exhibits the same problem. > > If that works, we can consider just adding those backwards compatibility > symlinks, because they won't hurt anyone. Okay, so this is where it dies a death with a symlink in ~/Gentoo/tmp/usr/lib/libc.dsym: /Users/sam/Gentoo/tmp/bin/bash /Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/libgcc/../mkinstalldirs . /Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc -B/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -B/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/bin/ -B/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/lib/ -isystem /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/include -isystem /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/sys-include -O2 -g -pipe -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -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 /Users/sam/Gentoo/tmp/usr/lib/gcc/x86_64-apple-darwin20/10.1.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: warning: building for macOS 10.4 is deprecated ld: library not found for -lc I think it might be worth pointing out at this point that the modifiations I've made are: 1) Drop filter-flags in toolchain.eclass; 2) Set export CPPFLAGS="-isystem ${ROOT}/tmp/usr/include -isystem ${ROOT}/MacOSX.sdk/usr/include" I've tried a few other things but that didn't get me anywhere. Someone else had a similar issue here: https://github.com/NixOS/nixpkgs/issues/14812 but the fix doesn't make sense to me, so not sure if it's the same problem. I've attached the failing command + output with -v. I created libc.dylib in ~/Gentoo/tmp/usr/lib/ and, to be doubly sure, I did the same thing in /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/lib. Oh, hang on. The symlink dest doesn't exist. (In reply to Sam James from comment #7) > Great: https://developer.apple.com/forums/thread/655588 OK. With this in mind: "ld: warning: building for macOS 10.4 is deprecated ld: warning: could not create compact unwind for __Unwind_RaiseException: does not use RBP or RSP based frame ld: warning: could not create compact unwind for __Unwind_RaiseException.cold: non-standard register 0 being saved in prolog ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: does not use RBP or RSP based frame ld: warning: could not create compact unwind for __Unwind_Resume: non-standard register 0 being saved in prolog ld: warning: could not create compact unwind for __Unwind_Resume.cold: non-standard register 0 being saved in prolog ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow: does not use RBP or RSP based frame ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow.cold: non-standard register 0 being saved in prolog ld: warning: dylib (/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/lib/libc.dylib) was built for newer macOS version (10.7) than being linked (10.4) ld: warning: dylib (/nix/store/h144jawqa92rqjhaahrsikq5j2dwkh5n-Libsystem-osx-10.12.6/lib/system/libsystem_c.dylib) was built for newer macOS version (10.7) than being linked (10.4) ld: warning: dylib (/nix/store/h144jawqa92rqjhaahrsikq5j2dwkh5n-Libsystem-osx-10.12.6/lib/system/libsystem_kernel.dylib) was built for newer macOS version (10.7) than being linked (10.4) ld: warning: dylib (/nix/store/h144jawqa92rqjhaahrsikq5j2dwkh5n-Libsystem-osx-10.12.6/lib/libSystem_internal.dylib) was built for newer macOS version (10.7) than being linked (10.4) ld: file not found: /usr/lib/system/libcache.dylib for architecture x86_64 collect2: error: ld returned 1 exit status make[2]: *** [Makefile:994: libgcc_s.dylib] Error 1 make[2]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/x86_64-apple-darwin20/libgcc' make[1]: *** [Makefile:11765: all-target-libgcc] Error 2 make[1]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build' make: *** [Makefile:988: all] Error 2" You can tell that I copied a random libSystem.B.dylib from a Nix copy I had lying around. I won't be doing that again. So, we need a genuinue method to grab these libraries from the system cache. Bleh. (Interesting read: https://mjtsai.com/blog/2020/06/26/reverse-engineering-macos-11-0/#comment-3257539). (In reply to Sam James from comment #5) > (In reply to Fabian Groffen from comment #4) > > Now, just -lc problems, that's an easy fix! Just symlink libc.dylib to > > libSystem.dylib. In fact, you can just do that in your prefix, thus > > $EPREFIX/usr/lib/libc.dylib -> /usr/lib/libSystem.dylib. Same trick you can > > repeat for libm if that exhibits the same problem. > > > > If that works, we can consider just adding those backwards compatibility > > symlinks, because they won't hurt anyone. > > Okay, so this is where it dies a death with a symlink in > ~/Gentoo/tmp/usr/lib/libc.dsym: [snip] > ld: warning: building for macOS 10.4 is deprecated > ld: library not found for -lc Ahhhh... This is what I get for not asking more about why, but just trying to fix it. macOS 10.4 (well, at that time it was called Mac OS X Tiger 10.4) is very old, and indeed had a libc.dylib (pointing to libSystem.dylib). The compiler spec cc1 mumbo jumbo simply injects -lc because it thinks it is targetting 10.4 (Tiger!). That is probably because MACOSX_DEPLOYMENT_TARGET is not understood correctly. Do you have the big-sur patch I committed? https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=ae2fe55112b538d23327e62ef28dfe5e0063b4de > I think it might be worth pointing out at this point that the modifiations > I've made are: > 1) Drop filter-flags in toolchain.eclass; > 2) Set > export CPPFLAGS="-isystem ${ROOT}/tmp/usr/include -isystem > ${ROOT}/MacOSX.sdk/usr/include" > > I've tried a few other things but that didn't get me anywhere. > > Someone else had a similar issue here: > https://github.com/NixOS/nixpkgs/issues/14812 but the fix doesn't make sense > to me, so not sure if it's the same problem. > > I've attached the failing command + output with -v. > > I created libc.dylib in ~/Gentoo/tmp/usr/lib/ and, to be doubly sure, I did > the same thing in /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/lib. I think this is a decoy of the actual problem, so you best rm them again. I think that's what I get for going down a hole while a bit tired. I don't even have the excuse of not knowing about that GCC option because I've seen it before and messed with it.
Anyway:
"patching file gcc/config/i386/t-linux32 [ ok ]
* Applying darwin-libgcc_s-installname.patch ... [ ok ]
* Applying gcc-10.1.0-macos-bigsur.patch ... [ ok ]
* Applying gcc-10.1.0-darwin-auth-fixincludes.patch ... [ ok ]
* Applying gcc-10.1.0-darwin.patch ... <-- the macports one from earlier for configure [ ok ]
>>> Source prepared."
So, yes, I have the patch, I checked the bootstrap script for any leftovers from previous meddling but nothing. I even set MACOSX_DEPLOYMENT_TARGET=11.0 when invoking the script but it still uses -mmacosx-version-min=10.4.
Pff. Both the "other" macports patch (https://github.com/macports/macports-ports/commit/53ad57cd08c5971b5a92df34d84e62589bc006b4.patch) and the one in the repo fail, resulting in -mmacosx-version-min=10.4 appearing. Wondering if https://trac.macports.org/ticket/61584 is somehow relevant (broken libtool). Okay, the auto-detection is definitely failing. Notice how my injected -mmacosx-version-min=11.0 *does* appear, but is joined by -mmacosx-version-min=10.4 later on. "/Users/sam/Gentoo/tmp/bin/bash /Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/gcc-10.1.0/libgcc/../mkinstalldirs . /Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc -B/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -B/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/bin/ -B/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/lib/ -isystem /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/include -isystem /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/sys-include -O2 -g -pipe -O2 -mmacosx-version-min=11.0 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -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 /Users/sam/Gentoo/tmp/usr/lib/gcc/x86_64-apple-darwin20/10.1.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 -mmacosx-version-min=11.0 -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 -lc collect2: error: ld returned 1 exit status" I took an axe to darwin-driver.c and it seems like I can get 10.16 to be used in theory, but then 10.4 still appears in the end. Out of ideas for now, may try hacking out parts of it again tomorrow. I feel like there's something stupid going on here with the detection but I can't even figure out *where* right now. (In reply to Sam James from comment #14) > I took an axe to darwin-driver.c and it seems like I can get 10.16 to be > used in theory, but then 10.4 still appears in the end. Out of ideas for > now, may try hacking out parts of it again tomorrow. > > I feel like there's something stupid going on here with the detection but I > can't even figure out *where* right now. Final update for the day (promise): diff --git a/libgcc/config/t-darwin b/libgcc/config/t-darwin index 3b5e342..acc9427 100644 --- a/libgcc/config/t-darwin +++ b/libgcc/config/t-darwin @@ -1,15 +1,15 @@ # Set this as a minimum (unless overriden by arch t-files) since it's a # reasonable lowest common denominator that works for all our archs. -HOST_LIBGCC2_CFLAGS += -mmacosx-version-min=10.4 +HOST_LIBGCC2_CFLAGS += -mmacosx-version-min=10.16 (and other changes in that file) have finally removed 10.4, like you'd expect, but the build still fails in exactly the same way, because I guess it's still misdetecting fundamentally what Darwin version we are. Hmm, I don't know why, but 10.1.0 actually bombs out for me on this:
libtool: link: g++ -m64 -o .libs/libcc1plugin.0.so -bundle .libs/libcc1plugin.o .libs/callbacks.o .libs/connection.o .libs/marshall.o -L/Users/fabian/Gentoo-11.0/tmp/usr/lib -m64 -Wl,-search_paths_first ../libiberty/pic/libiberty.a -Wl,-exported_symbols_list,.libs/libcc1plugin-symbols.expsym
Undefined symbols for architecture x86_64:
"build_decl(unsigned int, tree_code, tree_node*, tree_node*)", referenced from:
plugin_build_decl(cc1_plugin::connection*, char const*, gcc_c_symbol_kind, unsigned long long, char const*, unsigned long long, char const*, unsigned int) in libcc1plugin.o
plugin_build_record_type(cc1_plugin::connection*) in libcc1plugin.o
plugin_build_union_type(cc1_plugin::connection*) in libcc1plugin.o
plugin_build_add_field(cc1_plugin::connection*, unsigned long long, char const*, unsigned long long, unsigned long, unsigned long) in libcc1plugin.o
plugin_build_enum_type(cc1_plugin::connection*, unsigned long long) in libcc1plugin.o
plugin_build_add_enum_constant(cc1_plugin::connection*, unsigned long long, char const*, unsigned long) in libcc1plugin.o
plugin_build_constant(cc1_plugin::connection*, unsigned long long, char const*, unsigned long, char const*, unsigned int) in libcc1plugin.o
...
"fancy_abort(char const*, int, char const*)", referenced from:
plugin_context::plugin_context(int) in libcc1plug
....
...
..
(In reply to Fabian Groffen from comment #16) > Hmm, I don't know why, but 10.1.0 actually bombs out for me on this: > > libtool: link: g++ -m64 -o .libs/libcc1plugin.0.so -bundle > .libs/libcc1plugin.o .libs/callbacks.o .libs/connection.o .libs/marshall.o > -L/Users/fabian/Gentoo-11.0/tmp/usr/lib -m64 -Wl,-search_paths_first > ../libiberty/pic/libiberty.a > -Wl,-exported_symbols_list,.libs/libcc1plugin-symbols.expsym > Undefined symbols for architecture x86_64: > "build_decl(unsigned int, tree_code, tree_node*, tree_node*)", referenced > from: > plugin_build_decl(cc1_plugin::connection*, char const*, > gcc_c_symbol_kind, unsigned long long, char const*, unsigned long long, char > const*, unsigned int) in libcc1plugin.o > plugin_build_record_type(cc1_plugin::connection*) in libcc1plugin.o > plugin_build_union_type(cc1_plugin::connection*) in libcc1plugin.o > plugin_build_add_field(cc1_plugin::connection*, unsigned long long, > char const*, unsigned long long, unsigned long, unsigned long) in > libcc1plugin.o > plugin_build_enum_type(cc1_plugin::connection*, unsigned long long) in > libcc1plugin.o > plugin_build_add_enum_constant(cc1_plugin::connection*, unsigned long > long, char const*, unsigned long) in libcc1plugin.o > plugin_build_constant(cc1_plugin::connection*, unsigned long long, > char const*, unsigned long, char const*, unsigned int) in libcc1plugin.o > ... > "fancy_abort(char const*, int, char const*)", referenced from: > plugin_context::plugin_context(int) in libcc1plug > .... > ... > .. I've got *you* on this one! Use the patch from Comment #2 or we can do the proper libtool fix which is pending upstream (it's longer and invasive because it involves regenerating all the files). Great! Then let's first cook dinner, then I'll add/incorportate the patch and continue. Thanks for reminding me! :) (For posterity, proposed upstream patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559963.html) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=2095595a4b7842988400f550b10622ecdc3f7ef5 commit 2095595a4b7842988400f550b10622ecdc3f7ef5 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-11-26 18:58:21 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-11-26 18:58:21 +0000 sys-devel/gcc-10.1.0-r1: add fix undefined symbols Bug: https://bugs.gentoo.org/756160 Package-Manager: Portage-3.0.10-prefix, Repoman-3.0.2 RepoMan-Options: --force Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/gcc/gcc-10.1.0-r1.ebuild | 3 +++ 1 file changed, 3 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=4e754e319d2f3feb553e50ff74a2dda81abf03f0 commit 4e754e319d2f3feb553e50ff74a2dda81abf03f0 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-11-26 20:03:11 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-11-26 20:03:11 +0000 sys-devel/gcc-10.1.0-r1: avoid -lc linkage on Big Sur Bug: https://bugs.gentoo.org/756160 Package-Manager: Portage-3.0.10-prefix, Repoman-3.0.2 RepoMan-Options: --force Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/gcc/gcc-10.1.0-r1.ebuild | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) I was convinced I tried that before, and I think I had, but gave up because I presumably had something like this (just had it now):
I guess it's because the LDFLAGS don't seem to be preserved here (the lack of the undefined bit).
/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc -B/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/ -B/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/bin/ -B/Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/lib/ -isystem /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/include -isystem /Users/sam/Gentoo/tmp/usr/x86_64-apple-darwin20/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 /Users/sam/Gentoo/tmp/usr/lib/gcc/x86_64-apple-darwin20/10.1.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
ld: warning: building for macOS 10.4 is deprecated
ld: warning: could not create compact unwind for __Unwind_RaiseException: does not use RBP or RSP based frame
ld: warning: could not create compact unwind for __Unwind_RaiseException.cold: non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_ForcedUnwind: does not use RBP or RSP based frame
ld: warning: could not create compact unwind for __Unwind_Resume: non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_Resume.cold: non-standard register 0 being saved in prolog
ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow: does not use RBP or RSP based frame
ld: warning: could not create compact unwind for __Unwind_Resume_or_Rethrow.cold: non-standard register 0 being saved in prolog
Undefined symbols for architecture x86_64:
"__keymgr_get_and_lock_processwide_ptr", referenced from:
_live_image_destructor in unwind-dw2-fde-darwin_s.o
__Unwind_Find_FDE in unwind-dw2-fde-darwin_s.o
"__keymgr_set_and_unlock_processwide_ptr", referenced from:
_live_image_destructor in unwind-dw2-fde-darwin_s.o
__Unwind_Find_FDE in unwind-dw2-fde-darwin_s.o
"__keymgr_unlock_processwide_ptr", referenced from:
__Unwind_Find_FDE in unwind-dw2-fde-darwin_s.o
"_abort", referenced from:
___absvdi2.cold in _absvsi2_s.o
___absvsi2.cold in _absvsi2_s.o
___absvti2.cold in _absvdi2_s.o
___addvdi3.cold in _addvsi3_s.o
___addvsi3.cold in _addvsi3_s.o
___addvti3.cold in _addvdi3_s.o
___subvdi3.cold in _subvsi3_s.o
...
"_calloc", referenced from:
__Unwind_Find_FDE in unwind-dw2-fde-darwin_s.o
___emutls_get_address in emutls_s.o
"_free", referenced from:
_search_object in unwind-dw2-fde-darwin_s.o
___deregister_frame_info_bases in unwind-dw2-fde-darwin_s.o
_live_image_destructor in unwind-dw2-fde-darwin_s.o
___deregister_frame in unwind-dw2-fde-darwin_s.o
_emutls_destroy in emutls_s.o
"_getpagesize", referenced from:
___enable_execute_stack in enable-execute-stack_s.o
"_getsectdatafromheader_64", referenced from:
__Unwind_Find_FDE in unwind-dw2-fde-darwin_s.o
"_malloc", referenced from:
_search_object in unwind-dw2-fde-darwin_s.o
___register_frame in unwind-dw2-fde-darwin_s.o
___register_frame_table in unwind-dw2-fde-darwin_s.o
___emutls_get_address in emutls_s.o
"_memcpy", referenced from:
_uw_install_context_1 in unwind-dw2_s.o
_uw_update_context_1 in unwind-dw2_s.o
_execute_cfa_program in unwind-dw2_s.o
__Unwind_RaiseException in unwind-dw2_s.o
__Unwind_ForcedUnwind in unwind-dw2_s.o
__Unwind_Resume in unwind-dw2_s.o
___emutls_get_address in emutls_s.o
...
"_memset", referenced from:
___emutls_get_address in emutls_s.o
"_mprotect", referenced from:
___enable_execute_stack in enable-execute-stack_s.o
"_pthread_getspecific", referenced from:
___emutls_get_address in emutls_s.o
"_pthread_key_create", referenced from:
_emutls_init in emutls_s.o
"_pthread_mutex_lock", referenced from:
___emutls_get_address in emutls_s.o
"_pthread_mutex_unlock", referenced from:
___emutls_get_address in emutls_s.o
"_pthread_once", referenced from:
_uw_init_context_1 in unwind-dw2_s.o
___emutls_get_address in emutls_s.o
"_pthread_setspecific", referenced from:
___emutls_get_address in emutls_s.o
"_realloc", referenced from:
___emutls_get_address in emutls_s.o
"_strlen", referenced from:
_uw_frame_state_for in unwind-dw2_s.o
_get_cie_encoding in unwind-dw2-fde-darwin_s.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:994: libgcc_s.dylib] Error 1
make[3]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/x86_64-apple-darwin20/libgcc'
make[2]: *** [Makefile:16386: all-stage1-target-libgcc] Error 2
make[2]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build'
make[1]: *** [Makefile:20640: stage1-bubble] Error 2
make[1]: Leaving directory '/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build'
make: *** [Makefile:20956: bootstrap-lean] Error 2
Ah. If I force in the undefined stuff in the t file, I get a compiler which can't find -lSystem: $ /Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/./gcc/xgcc -print-search-dirs install: /Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/ programs: =/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../libexec/gcc/x86_64-apple-darwin20/10.1.0/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../libexec/gcc/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/../../../../x86_64-apple-darwin20/bin/x86_64-apple-darwin20/10.1.0/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/../../../../x86_64-apple-darwin20/bin/ libraries: =/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/:./x86_64-apple-darwin20/10.1.0/:./:/usr/local/lib/x86_64-apple-darwin20/10.1.0/:/usr/local/lib/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/../../../../x86_64-apple-darwin20/lib/x86_64-apple-darwin20/10.1.0/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/../../../../x86_64-apple-darwin20/lib/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/../../../x86_64-apple-darwin20/10.1.0/:/Users/sam/Gentoo/tmp/var/tmp/portage/sys-devel/gcc-10.1.0-r1/work/build/gcc/../../../lib/gcc/x86_64-apple-darwin20/10.1.0/../../../ None of the interesting directories (if any at all) actually exist, so I guess it figures. I bet that this is the problem: configure:29617: checking linker --sysroot support configure:29633: result: no because we see -isysroot being used, but it isn't translated into -syslibroot argument to ld, which tells it where it can find all libraries (the SDK). HAVE_LD_SYSROOT controls this in gcc/config/darwin.h What is weird, is that this apparently doesn't bother on 10.15, but perhaps this is so, because there /usr/lib is still populated. So maybe gcc/configure.ac needs to be taught to detect it on Darwin, but probably easier, just export gcc_cv_ld_sysroot=yes The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=51f9736209cc2077ba957becf2523f22329d5aa7 commit 51f9736209cc2077ba957becf2523f22329d5aa7 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-11-26 20:49:24 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-11-26 20:49:24 +0000 sys-devel/gcc-10.1.0-r1: next attempt at linkage on Big Sur Bug: https://bugs.gentoo.org/756160 Package-Manager: Portage-3.0.10-prefix, Repoman-3.0.2 RepoMan-Options: --force Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/gcc/gcc-10.1.0-r1.ebuild | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) Created attachment 675397 [details, diff]
gcc-10.1.0-macos-slibgcc-undefined-libtool.patch
Yeah, this built for me with:
# fix for Big Sur versioning, remove with 11
eapply -p1 "${FILESDIR}"/${PN}-10.1.0-macos-bigsur.patch
# custom
eapply -p1 "${FILESDIR}"/${PN}-macos-slibgcc-undefined-libtool.patch
find . -name "configure" | xargs \
sed -i -e '/^\s*10\.\*)/N' \
-e '/^\s*10\.\*)\s*_lt_dar_allow_undefined/s/10\.\*/10.*|11.*/' || die
if [[ ${CHOST} == *-darwin20 ]] ; then
# drop -lc, it isn't there (any more?)
sed -i -e '/^SHLIB_LC =/s/=.*$/=/' \
libgcc/config/t-slibgcc-darwin || die
fi
I did inject the big libtool one which the sed replicates but I think that was just experimenting for another error I had. So it's just the one I attached, plus the sed.
I don't quite get it, the in-tree gcc-10.1.0 just works for me, do you need additional changes? (In reply to Fabian Groffen from comment #27) > I don't quite get it, the in-tree gcc-10.1.0 just works for me, do you need > additional changes? I'll re-run and check. By the way, with =dev-vcs/git-2.29.2, I get: In file included from /Users/sam/Gentoo/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32, from /Users/sam/Gentoo/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:42, from git-credential-osxkeychain.c:4: /Users/sam/Gentoo/MacOSX.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7: error: variably modified ‘bytes’ at file scope 193 | char bytes[kAuthorizationExternalFormLength]; | ^~~~~ I thought this was patched in GCC but maybe not? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 you already found it :) for gnutls I simply disabled it, because that code was trying to use the system certificate store, and we'd want it (also git) to use the ca-certificates we install ourselves, so 2 birds 1 stone. Perhaps we can do the same thing for git too, so we can at least install it for now. (In reply to Fabian Groffen from comment #29) > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 > > you already found it :) \o/. Not seeming to respect the SDK dir is a bit irritating. > > for gnutls I simply disabled it, because that code was trying to use the > system certificate store, and we'd want it (also git) to use the > ca-certificates we install ourselves, so 2 birds 1 stone. Perhaps we can do > the same thing for git too, so we can at least install it for now. For now, I've done a very bad thing: a poor man's overlayfs, essentially (just symlinked everything but Authorization.h, because I wanted git keychain integration), but we'll have to patch it out for now, yeah. Wondering if there's some tool we could use to emulate overlayfs like that and have our own "fixups" if needed, ala gcc. we need to figure out how the framework includes are located, e.g. can we just stash stuff in include-fixed, or do we need a different dir/patch. I know there are framework searchpaths, so the only thing we need to do, is to put a patched copy of the framework header file in search path. The $EPREFIX/Frameworks dir for instance should be such one. I think we fixed this, yay :) |