FreeCAD 0.17 && /lib//libgcc_s.so.1

[Tijl Coosemans]

On Fri, 22 Feb 2019 19:14:33 +0200 Konstantin Belousov
<kostikbel at gmail.com> wrote:
> On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
>> 1) GCC can add new symbols or new versions of them with every release
>> which means the problem can reappear with every new GCC release and GCC
>> releases aren't aligned with FreeBSD releases.  
> Right, this is known and accepted ABI changes.  We must cope with them
> if we intend to run newer gcc and newer gcc' compiled binaries.
> 
>> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
>> runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
>> these symbols so why should we implement these third party compiler
>> runtime helper functions?  
> Because we strive to provide a usable system, not locked to one compiler.
> IMO we must support both gcc and clang and their compilation results,
> each with some version variance, regardless of the compiler used for
> the base system.
> 
>> 3) With my gfortran patch you don't need to implement anything.  It's an
>> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD.  
> Because all missed symbols are resolved from the compiler's libgcc.a before
> linker insert a reference to libgcc_s.so.1, or due to some other cause ?

Yes, for clang/clang++/gcc if you compile with -### you'll see this:
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
=> only code that uses stack unwinding uses libgcc_s

For gfortran/g++ you'll see this:
-lgcc_s -lgcc
=> almost all code uses libgcc_s

gcc/g++/gfortran also accept -shared-libgcc and -static-libgcc command
line arguments but nobody uses these.  clang/clang++ does not seem to
support them.
-shared-libgcc: -lgcc_s -lgcc => almost all code uses libgcc_s
-static-libgcc: -lgcc => nothing uses libgcc_s

libgcc.a: contains compiler runtime functions.  I don't really consider
these part of the ABI.
libgcc_s.so: contains most of the functions of libgcc.a and also _Unwind*
functions which are part of the ABI.

clang/clang++ will never use the compiler runtime functions in
libgcc_s.so because it always links with libgcc.a first.

gcc/g++/gfortran link with -L/usr/local/lib/gcc* internally so at
compile time they always use their own libgcc.a and libgcc_s.so.

If you apply my ldconfig patch it will list gcc libgcc_s.so before the
base system libgcc_s.so so you don't have to patch gfortran.

If you apply my gfortran patch it will only need libgcc_s.so for stack
unwinding which our libgcc_s.so handles just fine so you don't need the
ldconfig patch (although it still helps to sort multiple versions of
other gcc runtime libraries).

Either way, our libgcc_s.so only needs to provide _Unwind* and nothing
else.  This doesn't lock FreeBSD to one compiler.

It may be useful to add __float128 functions to our libgcc.a to enable
clang __float128 support.  I haven't looked into that.