tl;dr: One question to build maintainers, and one patch submitted to toplevel configure.ac
--------------- I’m looked into the issue some more, and am comparing two builds of trunk (exact same source), one configured with system compiler (clang) in PATH, the other with GCC 4.9.2 in PATH. At the toplevel configure, the only meaningful difference is that the gcc-based build sets stage1_ldflags='-static-libstdc++ -static-libgcc' while the clang-based has stage1_ldflags='' (clang doesn’t recognized -static-libstdc++). This is included into the toplevel Makefile as STAGE1_LDFLAGS (the comment appropriately says "Linker flags to use on the host, for stage1 or when not bootstrapping”). Those are exported by HOST_EXPORTS, which is are then used by configure-libcc1, all-libcc1, etc. Thus, we end up using STAGE1_LDFLAGS, which correspond to the system compiler, instead of the stage3 compiler (as we should). So, this is “false negative” part of the problem (namely, why we don’t see the failure when bootstrapping with clang): we use STAGE1_LDFLAGS in building libcc1, and with clang as system compiler we don’t use static linking of the C++ library. This part, I don’t know how to fix: it is for the build experts to address. It is a real problem: it leads to libcc1.so being linked dynamically to libstdc++ and libgcc, instead of statically (as it should). --------------- Second part of the question: when the freshly built g++ is used, we need to pass the appropriate -B options. As I understand it, the appropriate place for that is in the toplevel configure.ac, where we already pass down the respective -L options. Indeed, the attached patch restores bootstrap on x86_64-apple-darwin14 with gcc as system compiler (and doesn’t break the bootstrap with clang as system compiler). OK to commit? FX PS: HJ, the reason only don’t see this on Linux is that only Darwin (AFAIK) plays spec tricks with static-libstdc++ (in gcc/config/darwin.h)
libcc1.ChangeLog
Description: Binary data
libcc1.diff
Description: Binary data
