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

[Steve Kargl]

On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote:
> On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce <db at db.net> wrote:
> > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote:
> >> So I must dig deeper.  Perhaps with rpaths interacting with the system
> >> paths?
> > 
> > You got it. ;)
> > Except python doesn't have an rpath which is why this keeps coming
> > up over and over again.
> 
> Maybe we should just add the gcc rpaths to the python ports LDFLAGS
> without depending on gcc.  Then python should use gcc libgcc_s when
> it exists and fall back to base system libgcc_s when it doesn't.
> 
> Maybe we should compile *all* ports with gcc rpaths without depending
> on gcc, just like we already compile everything with -fstack-protector
> in LDFLAGS.
> 
> 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

> 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?

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.

As anyone tried adding an empty sections to FreeBSD's
libgcc_s,

/*
 * Empty sections to work around FreeBSD abusing the name 
 * of a well-known GCC library.
 */
GCC_4.6.0 {

} GCC_4.3.0;

GCC_4.7.0 {

} GCC_4.6.0;

GCC_4.8.0 {

} GCC_4.7.0;

GCC_7.0.0 {

} GCC_4.8.0;



-- 
Steve