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

[Konstantin Belousov]

On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote:
> 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.
Right, this is known and accepted ABI changes.  We must cope with them
if we intend to run newer gcc and newer gcc' compiled binaries.

> 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 we strive to provide a usable system, not locked to one compiler.
IMO we must support both gcc and clang and their compilation results,
each with some version variance, regardless of the compiler used for
the base system.

> 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.
Because all missed symbols are resolved from the compiler's libgcc.a before
linker insert a reference to libgcc_s.so.1, or due to some other cause ?