Date: Fri, 22 Feb 2019 08:44:54 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: =?utf-8?Q?T=C4=B3l?= Coosemans <tijl@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222164454.GA33338@troutmask.apl.washington.edu> In-Reply-To: <20190222170959.02047c69@kalimero.tijl.coosemans.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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. 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. > 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?20190222164454.GA33338>