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

[Tijl Coosemans]

On Fri, 22 Feb 2019 08:44:54 -0800 Steve Kargl
<sgk at troutmask.apl.washington.edu> wrote:
> On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
>> On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
>>> Do you agree that the ultimate and proper solution is to add missed symbols
>>> and versions to the base libgcc_s.so.1 ?  IMO it is, and this thread started
>>> to show some work which might finally solve that.
>>> (But about as-needed for libgfortran see above).  
>> 
>> Not really no:
>> 
>> 1) GCC can add new symbols or new versions of them with every release
>> which means the problem can reappear with every new GCC release and GCC
>> releases aren't aligned with FreeBSD releases.  
> 
> GCC developers do add new symbols.  Not sure what you mean by
> new versions.  The ABI is stable.  If they change the ABI, then
> they would bump the major number to 2.

The symbol versions like GCC_4.6.0.  The library uses symbol versioning
so they can add new versions of the same symbol without removing the old
versions.  This way adding new versions of a symbol doesn't change the
ABI.

>> 2) Base system libgcc is essentially libcompilerrt, the LLVM compiler
>> runtime.  LLVM doesn't seem to need these symbols, nothing in base needs
>> these symbols so why should we implement these third party compiler
>> runtime helper functions?  
> 
> Because FreeBSD usurped the name of a well-known library from a
> well-known open source project.  Users might expect that that
> well-known library has the same ABI and functionality of the
> library provided by the well-known project.
> 
> If nothing in base needs /lib/libgcc_s, then let's remove it.
> If nothing in base needs it, let's rename name it to libfreebsd_s.so.

Clang uses the name libgcc_s so clang compiled code can throw exceptions
to gcc compiled code and vice versa.

I suspect that FreeBSD libgcc_s only needs to provide the _Unwind*
symbols and nothing else.  Then it could be renamed to libunwind or
something and then gcc could be patched so its libgcc_s no longer
provides _Unwind* and instead links to the FreeBSD libunwind.  Then
clang also needs to be patched to use libunwind instead of libgcc_s.
It's just easier to keep using the name libgcc_s.  It was perhaps a
mistake of the GCC developers to put compiler runtime functions, which
are compiler specific, and stack unwinding, which is part of the system
ABI that is common to all compilers, in one library.

>> 3) With my gfortran patch you don't need to implement anything.  It's an
>> apply-once-and-stop-worrying-about-it solution for all versions of FreeBSD.  
> 
> Your patching a gfortran spec file.  Don't you need to worry
> about the spec file changing, which may invalidate your patch?

Yes, I'll give you that one.  The patch has to be kept up-to-date, but
that's trivial compared to making FreeBSD erratas when a new gcc
release adds a new function to libgcc.