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

[Tijl Coosemans]

On Fri, 22 Feb 2019 15:39:17 +0200 Konstantin Belousov
<kostikbel at gmail.com> wrote:
> Yes, we absolutely must avoid situation where two similar libraries
> (i.e. providing some subset of symbols from other) are linked into the
> same executing process.
> 
> I think your patches would be a definitive improvement, esp. the part
> which makes libgfortran linking only as needed.
> 
> For the other part, which makes the ports dso a priority over the base
> dso, I would exercise some more causion. For ports we know only about
> libgcc_s.so.1 which has the same name in base and in ports, other
> libraries in base should have libprivate suffix to not conflict, right ?
> What about openssl libraries ?

As long as libraries have a different name the search order in the
ldconfig cache doesn't matter.  So libfoo.so.x and libprivatefoo.so.x
don't conflict but neither do libfoo.so.x and libfoo.so.y.  Some
libraries in base have the libprivate prefix and they are not meant to
be used by ports at all.  The openssl libraries in base have a different
version suffix than security/openssl* and are allowed to be used by
ports.

> I think such setup makes it easier for user to accidentaly break the system.
> She could install something manually (not from ports), or copy some file
> into /usr/local/lib, which conflicts with base and cause troubles.

Or they could copy something in /lib or /usr/lib and break their system.

The idea behind the ldconfig patch is that the runtime search order
should be as close as possible to a typical compile time order.
Typically compilers and linkers search /usr/local before /usr, so
ldconfig should search /usr/local before /usr.  Anyone that wants a
different order needs to provide a good explanation for that and I don't
think protecting users from shooting themselves in the foot is a good
enough reason.

Similarly, I think our default PATH is also backwards.  Major Linux
distros and MacOS all put /usr/local/bin before /usr/bin.

# User can override sysadmin who can override OS:
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin

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