Date: Fri, 22 Feb 2019 19:09:11 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: =?utf-8?Q?T=C4=B3l?= Coosemans <tijl@freebsd.org>, FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222170911.GA2420@kib.kiev.ua> In-Reply-To: <20190222164454.GA33338@troutmask.apl.washington.edu> References: <a2102b4e-7d7a-7d5b-2ba1-b9a14f8574f6@pinyon.org> <f6a45ec9-7ae4-d9ba-f71c-f2ef8c235039@grosbein.net> <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <092b17f0-6fbf-662e-1061-403442248abd@pinyon.org> <20190222140407.2145c11e@kalimero.tijl.coosemans.org> <20190222133917.GZ2420@kib.kiev.ua> <20190222170959.02047c69@kalimero.tijl.coosemans.org> <20190222164454.GA33338@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190222170911.GA2420>