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

[Tijl Coosemans]

On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl
<sgk at troutmask.apl.washington.edu> wrote:
> On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
>> There's also the fact that gfortran behaves differently from the C
>> compilers (both clang and gcc) when it comes to libgcc_s.  Gfortran
>> always links with libgcc_s.  The C compilers link with libgcc.a first
>> and then with libgcc_s only as needed.  
> 
> libgfortran is gfortran's runtime library.  libgcc.a is gcc's 
> runtime library.  The link orders are the same:  libgfortran
> then libgcc_s; libgcc then libgcc_s

No, libgcc is the runtime library for the entire compiler collection not
just the C compiler.  The order of libgcc.a and libgcc_s.so can be
changed with -static-libgcc and -shared-libgcc:

For the C compiler:

default:  libgcc.a -Wl,--as-needed libgcc_s.so -Wl,--no-as-needed
-static-libgcc: libgcc.a
-shared-libgcc: libgcc_s.so libgcc.a

For gfortran:

default: libgcc_s.so libgcc.a (like -shared-libgcc)
-static-libgcc: libgcc.a
-shared-libgcc: libgcc_s.so libgcc.a

What my patch does is change the gfortran default into the C compiler
default.

>> This eliminates almost all
>> links with libgcc_s.  The only ones left are for exception handling
>> and stack unwinding and gcc libgcc_s and base system libgcc_s are
>> version compatible for that so it doesn't matter which one gets picked
>> up.  The attached patch for lang/gcc8 makes gfortran behave just like
>> the C compilers.  
> 
> Just add -static to FFLAGS.  Yep, you're building static
> libraries.
> 
>> We cannot rename the base system libgcc_s to libclang_s because then a
>> process could load both gcc libgcc_s and base system libclang_s and I
>> think that could break exception handling and stack unwinding in weird
>> ways.  
> 
> Wouldn't that be a bug in the program that loads both?

Perhaps yes, but it's same as with missing -rpath.  We don't want to
have to fix those bugs and we don't want users be confronted with them.

> BTW, if you compare gcc trunks symbol map
> ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map
> with src/lib/libgcc_s/Version.map, you'll find that
> that maps are no one-to-one.

Yes, libgcc_s implements stack unwinding and exception handling and
libgcc.a does not.  The stack unwinding and exception handling code has
to be shared so all code in a process uses the same implementation and
accompanying data structures.