https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61027
--- Comment #4 from simon at pushface dot org --- I think my use of --with-host-libstdcxx=-lstdc++ to avoid this problem came at it from slightly the wrong angle. It seems to me that it's more to do with -static-libgcc and the 4.9 change to use the C++ compiler as the basis for builds. In https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html it says <<< -shared-libgcc -static-libgcc On systems that provide libgcc as a shared library, these options force the use of either the shared or static version, respectively. If no shared version of libgcc was built when the compiler was configured, these options have no effect. There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc. Therefore, the G++ and GCJ drivers automatically add -shared-libgcc whenever you build a shared library or a main executable, because C++ and Java programs typically use exceptions, so this is the right thing to do. If, instead, you use the GCC driver to create shared libraries, you may find that they are not always linked with the shared libgcc. If GCC finds, at its configuration time, that you have a non-GNU linker or a GNU linker that does not support option --eh-frame-hdr, it links the shared version of libgcc into shared libraries by default. Otherwise, it takes advantage of the linker and optimizes away the linking with the shared version of libgcc, linking with the static version of libgcc by default. This allows exceptions to propagate through such shared libraries without incurring relocation costs at library load time. However, if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ or GCJ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc. >>> and --with-host-libstdcxx=-lstdc++ does this as a side-effect when building gnattools/. This doesn't work when building a cross-compiler, because the tools are built by gcc/ada/gcc-interface/Makefile.in which contains # Link flags used to build gnat tools. By default we prefer to statically # link with libgcc to avoid a dependency on shared libgcc (which is tricky # to deal with as it may conflict with the libgcc provided by the system). GCC_LINK_FLAGS=-static-libstdc++ -static-libgcc (there's a later setting in the target_os~=darwin section, too, just -static-libstdc++ this time). *********** * As a side question, is it proper for the Ada makefiles to override * the decisions made in the top-level configure/Makefile settings? *********** So I patched these out (pr61027-1.diff) and configured the cross-compiler with --with-stage1-libs=no --with-stage1-ldflags=no (these affect the top-level settings of LDFLAGS); the cross-compiler built OK and arm-eabi-gnat doesn't give the SEGV. I expect the same flags would be right for a --disable-bootstrap build. I haven't yet tried the equivalent for a full build (--with-boot-libs=no --with-boot-ldflags=no). It seems likely that this is a Darwin problem only; I don't know how to approach this as a top-level issue (do other languages use exceptions? given the recommendations above re: -static-libgcc, should the configure.ac default settings of stage1_ldflags and poststage1_ldflags include -static-libgcc?)
