On Thu, 21 Feb 2019 10:24:51 -0800 Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl 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. > > libgfortran is gfortran's runtime library. libgcc.a is gcc's > 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. > > Just add -static to FFLAGS. Yep, you're building static > libraries. > >> 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. > > 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. _______________________________________________ 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"
