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

[Steve Kargl]

On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote:
> > 
> > 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.
> Nothing was usurped, you can lower your tone.
> 
> Initially libgcc_s.so.1 was provided by gcc and the library was updated
> during the regular gcc imports. When gcc changed the license, the
> libgcc_s.so.1 become stalled due to the block on the import of the new
> gcc versions.

I know the history.  When FreeBSD decided to move away from 
gcc, then it should move away.  That includes either removing
libgcc_s.so or renaming it.  As it is now, FreeBSD libgcc_s.so
does not provide the ABI in the official libgcc_s.so as
distributed with any version of gcc newer than gcc=4.5.z.
It clearly is causing problems.  

Yes, I know some oddball architectures cannot (or at least
could not) be compiled with clang/llvm, so contrib/gcc remains
in the tree.  In these special cases, then libgcc_s.so can be
installed as part of installing contrib/gcc.

> Some parts of gcc-provided libgcc_s.so.1 were replaced with llvm unwinder,
> some parts with compiler-rt functions.  The new functions added by gcc
> were not imported because nobody who can do that knew about the problem.
> Generic hand-waving is not the problem description.
> 
> Now, that the list of missing symbols is collected and possible sources
> for them are identified, at least some gaps can be filled.
> 
> > 
> > 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.
> This cannot be done, because it breaks the base system ABI. In
> particular, after that almost all compiled C++ apps will be broken, and
> significant amount of threaded programs as well.

Then the assertion that nothing in base needs libgcc_s.so is wrong?

And, yes, if an application is currently using /lib/libgcc_s.so,
then it would need to be recompiled.  When it is recompiled, it
can use libcompiler_rt or, if need be, it can use the libgcc_s.so
provided by a gcc port.

--   
Steve