Date: Sun, 14 Aug 2016 12:24:36 -0400 From: Diane Bruce <db@db.net> To: freebsd-toolchain@FreeBSD.org, freebsd-ports@freebsd.org Subject: Problems with our libgcc_s.so in base Message-ID: <20160814162436.GA32493@night.db.net>
next in thread | raw e-mail | index | archive | help
Problems with libgcc_s.so 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 libgcc_s.so 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/libquadmath.so
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 libgcc_s.so to claim
GCC_4.6, we really also should provide a libquadmath subsitute.
The other approach is to rename our libgcc_s.so to libclang_s.so or
some such and link base with it instead of libgcc_s.so
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}/libgcc_s.so
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.
Diane
--
- db@FreeBSD.org db@db.net http://www.db.net/~db
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160814162436.GA32493>