Synopsis:

macOS from 10.11 (darwin15) has a new measure of default system protection, where there is no "root" access to certain parts of the system (e.g. /usr etc.) and executables are protected from dynamic loader exploits - such as interposing unauthorised libraries using "DYLD_LIBARRY_PATH" (Darwin's equivalent of LD_LIBRARY_PATH).

Unfortunately, GCC's build and test environment relies on using DYLD_LIBRARY_PATH to point to the uninstalled libraries just built by the toolchain (these might even be needed during the actual build).

So, when SIP is enabled (the default), DYLD_xxx are silently ignored. By dumb luck mostly we are succeeding with builds - this is because the compiler is built with statically-linked libstdc++ & libgcc (technically the latter fires another problem, related to incorrect unwinder usage, but let's put that to one side, since GCC is not supposed to use exceptions).

Unprotected executables (e.g. the ones we build and the test suite exes) can use DYLD_LIBRARY_PATH so 

DYLD_LIBRARY_PATH=somewhere/with/a/test/library ./foo 

will work.

But
export DYLD_LIBRARY_PATH=somewhere/with/a/test/library

will not work, because that uses a "protected" binary (/use/bin/bash).

So .. I think that one needs to do

make install-target && make check.

To get meaningful test results with SIP enabled 

even so, the behaviour of configure tests might be suspect, if the result would depend on a built library rather than one installed on the system.

===== What to do?

(non)-Fix 
=========

Disable SIP.

This is not something we should be requiring - it's not really acceptable for the toolchain build to force reduction in system security measures.  However, Apple provides a mechanism for switching SIP off and when that is done DYLD_LIBRARY_PATH works again [and we then fire up PR84257 (since the handling of DYLD_LIBRARY_PATH with SIP switched off seems to be very slow)].

Possible fix #1
===============

This is what I've been tinkering with

1) convert all the target libraries to use @rpath/libxxxxx.dylib as their install names
2) get GCC to emit the necessary rpaths into executables during build and test (and, obviously, at install time).

Actually, this is sensibly in line with a useful macOS deployment model - since the "approved" way to package shared libraries on macOS / Darwin is to place them alongside the executables and use rpaths.

unfortunately:
 * it's quite an involved set of changes and almost certainly not going to happen for 9.
 * there are details to work out to make sure that build-time paths don't leak into installed libraries/exes.

Possible fix #2
===============

Have a build environment where all the used executables and paths are outside the remit of SIP.  This is untested so far, and might not suit the casual user of GCC - since it would involve building at least a shell / make / GCC prerequisites etc.