On Fri, 22 Feb 2019 19:14:33 +0200 Konstantin Belousov <kostik...@gmail.com> wrote: > On Fri, Feb 22, 2019 at 05:09:59PM +0100, Tijl Coosemans wrote: >> 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. > Right, this is known and accepted ABI changes. We must cope with them > if we intend to run newer gcc and newer gcc' compiled binaries. > >> 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 we strive to provide a usable system, not locked to one compiler. > IMO we must support both gcc and clang and their compilation results, > each with some version variance, regardless of the compiler used for > the base system. > >> 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. > Because all missed symbols are resolved from the compiler's libgcc.a before > linker insert a reference to libgcc_s.so.1, or due to some other cause ?
Yes, for clang/clang++/gcc if you compile with -### you'll see this: "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" => only code that uses stack unwinding uses libgcc_s For gfortran/g++ you'll see this: -lgcc_s -lgcc => almost all code uses libgcc_s gcc/g++/gfortran also accept -shared-libgcc and -static-libgcc command line arguments but nobody uses these. clang/clang++ does not seem to support them. -shared-libgcc: -lgcc_s -lgcc => almost all code uses libgcc_s -static-libgcc: -lgcc => nothing uses libgcc_s libgcc.a: contains compiler runtime functions. I don't really consider these part of the ABI. libgcc_s.so: contains most of the functions of libgcc.a and also _Unwind* functions which are part of the ABI. clang/clang++ will never use the compiler runtime functions in libgcc_s.so because it always links with libgcc.a first. gcc/g++/gfortran link with -L/usr/local/lib/gcc* internally so at compile time they always use their own libgcc.a and libgcc_s.so. If you apply my ldconfig patch it will list gcc libgcc_s.so before the base system libgcc_s.so so you don't have to patch gfortran. If you apply my gfortran patch it will only need libgcc_s.so for stack unwinding which our libgcc_s.so handles just fine so you don't need the ldconfig patch (although it still helps to sort multiple versions of other gcc runtime libraries). Either way, our libgcc_s.so only needs to provide _Unwind* and nothing else. This doesn't lock FreeBSD to one compiler. It may be useful to add __float128 functions to our libgcc.a to enable clang __float128 support. I haven't looked into that. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
