On Thu, Feb 21, 2019 at 06:05:15PM +0100, Tijl Coosemans wrote: > On Sun, 17 Feb 2019 10:16:04 -0500 Diane Bruce <d...@db.net> wrote: > > On Sat, Feb 16, 2019 at 06:35:52PM -0700, Russell L. Carter wrote: > >> So I must dig deeper. Perhaps with rpaths interacting with the system > >> paths? > > > > You got it. ;) > > Except python doesn't have an rpath which is why this keeps coming > > up over and over again. > > Maybe we should just add the gcc rpaths to the python ports LDFLAGS > without depending on gcc. Then python should use gcc libgcc_s when > it exists and fall back to base system libgcc_s when it doesn't.
Right. Or just provide a shell shim to LD_PRELOAD IFF it is noticed a specific port will require a fortran built binary module later. > > Maybe we should compile *all* ports with gcc rpaths without depending > on gcc, just like we already compile everything with -fstack-protector > in LDFLAGS. > > 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. This eliminates almost all What is really happening is gfortran links with libgfortran (surprise surprise) and libgfortran has the requirement for @GCC_4.6.0 or later > 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. Something like this was tried already. I'll have to dig into my old notes. > > 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. Yes yes and yes. It would be a right PITA. Perhaps it could be done with some weak symbols but personally I think that's another hack. I'll go look for whatever symbols we are missing and see if we can fix our libgcc_s ... Diane -- - d...@freebsd.org d...@db.net http://artemis.db.net/~db _______________________________________________ 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"
