libgcc errors

1) We can no longer ship a GPLv3 compiler in base due to 
   licencing concerns from 3rd parties
2) we could have kept on with the ancient gcc in base we had but
   it's horribly outdated and much code will no longer compile with it.
3) We decided to switch to clang since it has no GPLv3 limitation it's
   supported by Apple and others yada yada
4) To ease transition we decided to stick with gcc libs. This wasn't too
   strange at first since Clang had done similar with a hybrid clang
   front end but a gcc back end.
5) This also made it easier to double check kernel/base builds still
    worked with clang vs. gcc same libs involved.
6) This has the side effect of meaning our libgcc either has to claim it is
   the same version or better than any gcc external compiler we use or we
   have to ensure we use the libgcc shipped with external gcc compiler
7) We are now running into situations where programs we compile now notice 
   the out of date libgcc and cause problems. This is because we favour
   *our* base version of libgcc instead of /usr/local version.
8) one proposed solution (dim? emaste?) is to favour /usr/local/lib/gcc....
   libraries and load those first before base libraries
   this would fit in with separating base from tools 
   Presently When we start a program the run time linker loads in the
   libraries from local /usr instead of /usr/local (glossed details)
   So we then have *our* libgcc instead of the needed gcc libgcc
9) The ports team has wall papered over this underlying problem with
   always linking programs with the -Wl,rpath stanza to add a section to
   the linked program/object module to force loading of /usr/local libgcc
 a) They have only wall papered over for gfortran
 b) This means local GCC builds use our libgcc includes normal ${CC} use
    as well as Fortran. 
   In other words fortran only reveals the masked bug, not is the cause.
   Which leads us back in a giant circle to point 6i
   If we use our libgcc we have to ensure it is always at least as good
   as or better than any external gcc compiler from ports expects,
   with the same versioning provided.
10) In other words, our base libgcc is a gcc mimic at the moment
  a) Our libgcc is not GPL code (mostly afaik) now since it is actually
     libcompiler_rt plus a new libunwind etc.

There are bits and pieces of crt that also call into libgcc (crt etc.) 
Possible solutions include 

1) stop pretending we have a real libgcc and go with libcompiler_rt 
   plus missing bits and pieces
2) force load from /usr/local/lib etc.
 a) This is a potential huge security bug IMO. Imagine a gcc libgcc bug
    that can be exploited and also used by sshd or su
 3) dim(?) I think suggested we force ports gcc to DTRT and insert the -rpath
    when it links, but we essentially (partially) do this with compiler.mk
    This idea would have the benefit of DTRT even when doing a non port
    build.

Oh one little detail. It is possible to link against base libgcc start 
running then dlopen's another object which is linked against a port libgcc
and then fail because of either a missing symbol or a version mismatch