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

[Diane Bruce]

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.

Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed
a specific port will require a fortran built binary module later.

> 
> 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.  This eliminates almost all

What is really happening is gfortran links with libgfortran (surprise 
surprise) and libgfortran has the requirement for @GCC_4.6.0 or later

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

Something like this was tried already. I'll have to dig into
my old notes. 

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

Yes yes and yes. It would be a right PITA. Perhaps it could be done
with some weak symbols but personally I think that's another hack.
I'll go look for whatever symbols we are missing and see if we
can fix our libgcc_s

...

Diane
-- 
- db at FreeBSD.org db at db.net http://artemis.db.net/~db