Date: Fri, 22 Feb 2019 17:11:20 +0100 From: =?UTF-8?B?VMSzbA==?= Coosemans <tijl@FreeBSD.org> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: "Russell L. Carter" <rcarter@pinyon.org>, Diane Bruce <db@db.net>, FreeBSD Ports ML <freebsd-ports@freebsd.org>, Eugene Grosbein <eugen@grosbein.net> Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1 Message-ID: <20190222171120.0b4913c4@kalimero.tijl.coosemans.org> In-Reply-To: <20190221182451.GA82216@troutmask.apl.washington.edu> 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> <20190221182451.GA82216@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl <sgk@troutmask.apl.washington.edu> wrote: > On Thu, Feb 21, 2019 at 06:05:15PM +0100, T=C4=B3l Coosemans wrote: >> There's also the fact that gfortran behaves differently from the C >> compilers (both clang and gcc) when it comes to libgcc_s. Gfortran >> always links with libgcc_s. The C compilers link with libgcc.a first >> and then with libgcc_s only as needed. =20 >=20 > libgfortran is gfortran's runtime library. libgcc.a is gcc's=20 > runtime library. The link orders are the same: libgfortran > then libgcc_s; libgcc then libgcc_s No, libgcc is the runtime library for the entire compiler collection not just the C compiler. The order of libgcc.a and libgcc_s.so can be changed with -static-libgcc and -shared-libgcc: For the C compiler: default: libgcc.a -Wl,--as-needed libgcc_s.so -Wl,--no-as-needed -static-libgcc: libgcc.a -shared-libgcc: libgcc_s.so libgcc.a For gfortran: default: libgcc_s.so libgcc.a (like -shared-libgcc) -static-libgcc: libgcc.a -shared-libgcc: libgcc_s.so libgcc.a What my patch does is change the gfortran default into the C compiler default. >> This eliminates almost all >> links with libgcc_s. The only ones left are for exception handling >> and stack unwinding and gcc libgcc_s and base system libgcc_s are >> version compatible for that so it doesn't matter which one gets picked >> up. The attached patch for lang/gcc8 makes gfortran behave just like >> the C compilers. =20 >=20 > Just add -static to FFLAGS. Yep, you're building static > libraries. >=20 >> We cannot rename the base system libgcc_s to libclang_s because then a >> process could load both gcc libgcc_s and base system libclang_s and I >> think that could break exception handling and stack unwinding in weird >> ways. =20 >=20 > Wouldn't that be a bug in the program that loads both? Perhaps yes, but it's same as with missing -rpath. We don't want to have to fix those bugs and we don't want users be confronted with them. > BTW, if you compare gcc trunks symbol map > ./x86_64-unknown-freebsd13.0/libgcc/libgcc.map > with src/lib/libgcc_s/Version.map, you'll find that > that maps are no one-to-one. Yes, libgcc_s implements stack unwinding and exception handling and libgcc.a does not. The stack unwinding and exception handling code has to be shared so all code in a process uses the same implementation and accompanying data structures.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190222171120.0b4913c4>