Problems with our in base

Diane Bruce db at
Sun Aug 14 16:24:48 UTC 2016

Problems with in base

If you compile with gcc and use our base libgcc it should DTRT
*provided* our libgcc has defined functions that are up to date
with current libgcc
We compile with gcc, it needs foo() from libgcc to run
doesn't matter what foo() is (A typical function would be T __multi3)

So our libgcc provides a foo() and gcc is happy 

This means in theory, we can interchangeably use gcc and clang in ports.
This also means it made the initial port work from from gcc in base
to clang in base a lot easier.

The problems come when we try to use architectures not fully
supported by our or when we use fortran.

However, our libgcc lies in two ways
1) our libgcc is mostly not GPL code anymore, though there are
   bits and pieces of GPL depending on what we don't have.

  This includes (or did) some of the work ian@ was trying to do with arm,
  various bits that arm libgcc provides from gcc were missing.

2) It claims to be only up to date with GCC 4.2.4

  Everything is peachy keen until someone references a symbol which is in
  anything gcc compiled using a newer > GCC 4.2.4 compiler.

The moment you load libgfortran, it has a requirement for GCC_4.6 or better,
and if our libgcc is already loaded things fail.

The reason ports gcc now has this requirment on 4.6 or better is
fortran standard says we have to support quad floating point math.
e.g. /usr/local/lib/gccXX/ 

We *could* lie in our libgcc_s and claim to be 4.6 which would simply
mean libgfortran would not complain and simply load the missing libquadmath.

If we updated the claimed GCC version in our to claim
GCC_4.6, we really also should provide a libquadmath subsitute.

The other approach is to rename our to or
some such and link base with it instead of 

I frankly think this in the long term is the cleaner solution.

In the ports world, we have papered over this problem by adding
-Wl,-rpath=${_GCC_RUNTIME} or similar to force programs to link
against /usr/local/lib/gcc${GCCVERSION}/
However, any program that uses python to build has to be patched
to force this stanza and our ports cmake presently does not force 
this stanza to be added.  

- db at db at

More information about the freebsd-toolchain mailing list