libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

[Tijl Coosemans]

On Sun, 7 Apr 2019 23:57:12 -0700 Mark Millard via freebsd-ports
<freebsd-ports at freebsd.org> wrote:
> On 2019-Apr-7, at 22:16, Gerald Pfeifer <gerald at pfeifer.com> wrote:
>> Hmm, I received zero feedback on this proposal, when it appeared
>> important for a number of users.
>> 
>> What's your take, Andreas, Tijl (your patch essentially with a bit
>> of an updated description), and toolchain?
>> 
>> Gerald
>> 
>> On Wed, 27 Feb 2019, Gerald Pfeifer wrote:
>>> Hi Tijl, hi everyone,
>>> 
>>> and let me add Andreas who has been helping on the GCC side (both
>>> ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
>>>
>>> On Sun, 24 Feb 2019, Tijl Coosemans wrote:
>>>> GCC_4.3.0 instead of GCC_3.3.0.  The gcc commit that changed this
>>>> doesn't explain why this was done, but we'll have to make the same
>>>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is
>>>> part of the ABI).  This isn't a blocker for the patch.
>>>> 
>>>> I emailed the patch to gerald on 2017-02-21.  He responded in the usual
>>>> way that he prefers patches submitted upstream and because I thought the
>>>> patch would not be accepted upstream he proposed an alternative solution
>>>> where gcc would always add -rpath on FreeBSD so you didn't have to
>>>> specify it on the command line.  I responded this wouldn't fix the case
>>>> where clang was used as a linker (e.g. to combine fortran and c++ code
>>>> in one program) and that the FAQ on the gcc website said it was a bad
>>>> idea for other reasons.  I also said upstream might accept my patch if
>>>> it was a configure option but that the gcc configure scripts are
>>>> complicated and I didn't know where to add it exactly.  Then silence.
>>> 
>>> To move this forward, let me include an updated version of the patch
>>> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for
>>> consideration for our ports collection, initially for lang/gcc8 given
>>> that this is the default in the ports collection.
>>> 
>>> 
>>> (The lang/gcc* ports actually do carry local patches, e.g. for arm or
>>> powerpc or -fuse-ld=lld, but you are right that I usually try to get
>>> things upstream first, fixing things upstream myself when I can, or
>>> asking for help. The problem in this specific case was/is that I'm
>>> quite not enough into this area so cannot really assess and clearly
>>> stalling over that was not good.)
>>> 
>>> 
>>> Find patch-gfortran-libgcc attached which should simply plug into
>>> lang/gcc8/files and lang/gcc8-devel/files.
>>> 
>>> Feedback very welcome!
> 
> I'm not sure the following will be considered important
> for the above, but I'll note it in case.

I don't think it is relevant.  The patch only affects gfortran, not any
C/C++ compiler, and it only affects programs that currently don't run
because system libgcc_s is loaded as a dependency of some library while
another library later in the dependency chain needs gcc libgcc_s.  The
patch fixes this case by eliminating the need for gcc libgcc_s.  It does
not change which libgcc_s is loaded so any problem in the system
libgcc_s affects the same programs before and after the patch.