https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90330
--- Comment #24 from Matt Thompson <matthew.thompson at nasa dot gov> ---
(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.
Iain,
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...
> --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.
>
> 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:
c-family/c-spellcheck.o i386-c.o darwin-c.o \
cc1-checksum.o libbackend.a main.o libcommon-target.a libcommon.a
../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a ./../intl/libintl.a -liconv
../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a
../libdecnumber/libdecnumber.a
-L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./isl/.libs -lisl
-L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./gmp/.libs
-L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpfr/src/.libs
-L/Users/mathomp4/src/GCC/gcc-9.2.0-BUILD/./mpc/src/.libs -lmpc -lmpfr -lgmp
-L./../zlib -lz
l
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. And there's the usual autotools business of libraries repeating
(libcommon, libcpp).
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)
And my usual suggestion of "just add -lstd++ or lc++" when I see C++ link
issues probably isn't right when you might be building those libraries! :)
