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

[Tijl Coosemans]

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfortran8.patch
Type: text/x-patch
Size: 2017 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20190221/bf8a415a/attachment.bin>