https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Matt Thompson from comment #24) > (In reply to Iain Sandoe from comment #23) > > --with-sysroot=/opt/iains/SDKs/darwin18-2 > > ^^^^ this is the sysroot that will be built into the compiler and used > > automatically when it's invoked (in this case, the one from XC10.2 tools) > > you would put /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk here. > Thanks for the explanations. I'm trying a new build now with gcc-8.2.0 as > the compiler passed to configure. > > Here's a(nother dumb) question: let's assume everything works. How exactly > can one see what the sysroot is on a compiler? I.e., I could run "gcc-8.2.0 > -xyz" and see it looks for /usr/include, but "gcc-9.2.0 -xyz" would show the > /Library/Developer... gcc --print-sysroot gcc --help will show you the things that the driver can print for you and point to other help lines that might be useful. > > --enable-version-specific-runtime-libs > > ^^^ I prefer to use this, since it ensures that libraries are installed into > > version-specific paths and thus should never clash on a rebuild/update of > > the compiler. > > Huh. I'll keep this in mind. I'm not adding it yet, but I'll put it in my > notes for this compiler build. right, it should not affect your result. > > > > > CC='gcc --sysroot=/opt/iains/SDKs/darwin18' > > CXX='g++ --sysroot=/opt/iains/SDKs/darwin18' > > > > ^^^ these are invoking a GCC-8.3 that's placed first in my PATH, but using > > an older SDK that doesn't have the "zippered" TBD files (since the ld64 on > > that GCC-8 doesn't grok those). > > > > > > > > > > > > > Note, looking at Homebrew again, I do see they also build with: > > > > > > > > > > make BOOT_LDFLAGS=-Wl,-headerpad_max_install_names > > > > > > > > That is solving a different problem - where it would seem that they > > > > intend > > > > to use install_name_tool to update the install paths and are allowing > > > > the > > > > maximum space. > > > > > > > > > would that help? > > > > > > > > very unlikely. > > > > > > Huh. This might actually be something that we've hit in CMake on other > > > codes, but if it's not needed, I won't do it for now. > > > > Perhaps, but it should not affect the compiler bootstrap or install - the > > paths for the built libraries are set to their install versions at build > > time - so they should be "long enough". > > Oh, yes. I was thinking of things we'll be building with this new GCC. I > just wish I could figure out the build-with-clang issue. It's like it's > missing some C++ library in its link line: build with clang should (does for me) work :) > Now, I do think it's a bit odd that 'main.o' is *after* 'libbackend.a' as I > usually put all my .o first then my .a when I build, but I think that's just > stylistic. Actually, one difference from the "usual linker" rules on Darwin is that ld64 will repeatedly re-visit presented libraries (in their presented order) to satisfy symbols. There is no need for the dance of repeating .a files several times. > Plus the C++ is so dense I don't know what this is looking for: > > std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)", > referenced from: > ipa_icf::sem_item_optimizer::worklist_push(ipa_icf::congruence_class*) > in libbackend.a(ipa-icf.o) TBH, neither do I from that snippet - but I do think that a correctly installed command line tools should just succeed with. configure --prefix=/somewhere/nice --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk and use clang as the bootstrap compiler. [as an aside, I do wonder where you are getting your GMP, MPFR, MPC and (optionally) ISL from ?] - for the record I usually build them in-tree and thus they are bootstrapped with the compiler.
