Date: Thu, 10 May 2018 12:48:23 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: freebsd-hackers@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510194823.GA60567@troutmask.apl.washington.edu> In-Reply-To: <20180510190549.GB14916@britannica.bec.de> References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510190549.GB14916@britannica.bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Suppose project Ajax has libfoo.so.1 and project Nub has libfoo.so.1. You install Ajax first, ldconfig will find 42:-lfoo.1 => /usr/local/lib/ajax/libfoo.so.1 while project Nub's libfoo.so.1 is 666:-lfoo.1 => /usr/local/lib/nub/libfoo.so.1 You build your Nub project bar and go to execute bar where upon the runtime loader finds 42 instead of 666. 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 does not solve the above problem, because once re-ordered, anything compiled by the ajax project finds the wrong libfoo.so.1 library. 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. 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. [1] llvm+clang Added Tue Jun 2 17:58:47 2009 UTC (8 years, 11 months ago) by ed https://svnweb.freebsd.org/base?view=revision&revision=193326 [2] compiler-rt. Added Thu Oct 21 19:02:02 2010 UTC (7 years, 6 months ago) by ed https://svnweb.freebsd.org/base?view=revision&revision=214152 -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180510194823.GA60567>