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

[Tijl Coosemans]

On Thu, 21 Feb 2019 13:30:41 -0500 Diane Bruce <db at db.net> wrote:
> 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:  
>>> 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. 

With my patch libgfortran only needs GCC_4.2.0 and works with base
libgcc_s.