Date: Fri, 22 Feb 2019 10:27:30 -0800 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Konstantin Belousov <kostikbel@gmail.com> 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: <20190222182730.GA33829@troutmask.apl.washington.edu> In-Reply-To: <20190222170911.GA2420@kib.kiev.ua> References: <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> <20190222170911.GA2420@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 22, 2019 at 07:09:11PM +0200, Konstantin Belousov wrote: > On Fri, Feb 22, 2019 at 08:44:54AM -0800, Steve Kargl wrote: > > > > 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. I know the history. When FreeBSD decided to move away from gcc, then it should move away. That includes either removing libgcc_s.so or renaming it. As it is now, FreeBSD libgcc_s.so does not provide the ABI in the official libgcc_s.so as distributed with any version of gcc newer than gcc=4.5.z. It clearly is causing problems. Yes, I know some oddball architectures cannot (or at least could not) be compiled with clang/llvm, so contrib/gcc remains in the tree. In these special cases, then libgcc_s.so can be installed as part of installing contrib/gcc. > 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. Then the assertion that nothing in base needs libgcc_s.so is wrong? And, yes, if an application is currently using /lib/libgcc_s.so, then it would need to be recompiled. When it is recompiled, it can use libcompiler_rt or, if need be, it can use the libgcc_s.so provided by a gcc port. -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190222182730.GA33829>