FreeCAD 0.17 && /lib//libgcc_s.so.1
Konstantin Belousov
kostikbel at gmail.com
Fri Feb 22 17:09:20 UTC 2019
On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl 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
> > <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.
>
> 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.
They add new symbols and provide new symbol versions where these symbols
are assigned.
>
> > 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.
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.
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.
>
> > 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?
>
> --
> Steve
More information about the freebsd-ports
mailing list