Date: Fri, 22 Feb 2019 20:28:41 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans <tijl@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222202841.78c92696@kalimero.tijl.coosemans.org> In-Reply-To: <20190222171433.GB2420@kib.kiev.ua> 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> <20190222171433.GB2420@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Feb 2019 19:14:33 +0200 Konstantin Belousov <kostikbel@gmail.com> wrote: > On Fri, Feb 22, 2019 at 05:09:59PM +0100, T=C4=B3l 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. =20 > 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. >=20 >> 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? =20 > 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. >=20 >> 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 FreeB= SD. =20 > Because all missed symbols are resolved from the compiler's libgcc.a befo= re > 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" =3D> only code that uses stack unwinding uses libgcc_s For gfortran/g++ you'll see this: -lgcc_s -lgcc =3D> 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 =3D> almost all code uses libgcc_s -static-libgcc: -lgcc =3D> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190222202841.78c92696>