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 _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
