Date: Thu, 10 May 2018 22:22:27 +0200 From: Joerg Sonnenberger <joerg@bec.de> To: Steve Kargl <sgk@troutmask.apl.washington.edu> Cc: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510202227.GA6592@britannica.bec.de> In-Reply-To: <20180510194823.GA60567@troutmask.apl.washington.edu> References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de> <20180510194823.GA60567@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 10, 2018 at 12:48:23PM -0700, Steve Kargl wrote: > On Thu, May 10, 2018 at 09:05:49PM +0200, Joerg Sonnenberger wrote: > > On Wed, May 09, 2018 at 04:45:51PM -0700, Steve Kargl wrote: > > > In review PR 228007, it came to my attention some individuals are > > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > > issue". > > > > I don't get why you are blaming the FreeBSD loader. In fact, this is a > > pretty common issue and the fault is and has always been that the GCC > > ecosystem is extremely bad about mixing different GCC versions in the > > runtime environment. It tends to somewhat work as long as you make sure > > that the main binary is using the newest GCC version, but it can still > > fail even then. > > > > It is a runtime loader issue in that the loader cannot not > deal with a name clash. It is not supposed to. The soname identifies the object. If you end up with multiple different objects with the same soname, it is your fault. It's not something the loader can magically fix. > Tijl's suggested fix of re-ordering the list of hints so > gcc7's libgcc_s.so.1 is found before /lib/libgcc_s.so.1 > works around the issue of executables compiled by gfortran7 > getting the correct libgcc_s.so.1. It doesn't solve the problem because it assumes that gfortran7's libgcc_so.so.1 is a superset of /lib/libgcc_s.so.1. This is a very popular assumption in GCCland and it turns out to be false surprisingly often. > As to your comment "the fault is and has always been that > the GCC ecosystem is extremely bad about mixing different > GCC version". libgcc_s.so.1 is a symbol versioned shared > library. As long as the ABI of symbols are not changed, > one can add new symbols without bumping the library version > number. GCC has added symbols to libgcc_s.so.1 since gcc > 4.2.1, and FreeBSD has not stayed in-sync. This is missing the point. GCC assumes that it always gets its own version of libgcc_s.so, because of course you are always going to compile things with the newest GCC in your system. Ironically, symbol versioning makes this situation *worse*, because symbol lookup no longer falls through consistently. > If you want to get snarky about different projects, don't > you think that "the fault is and has always been that the > FreeBSD ecosystem" (mis)appropriated the name libgcc when > clang came into the tree [1] because clang didn't have a > runtime library [2] and it was expedient to simply use > libgcc_s.so.1. Again, you are missing that the situation would happen just the same if the base compiler is GCC 4.2.1 and not Clang. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180510202227.GA6592>