Date: Thu, 10 May 2018 08:15:22 -0700 From: Steve Kargl <sgk@troutmask.apl.washington.edu> To: Diane Bruce <db@db.net> Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, FreeBSD ports list <freebsd-ports@freebsd.org> Subject: Re: Runtime loader issue Message-ID: <20180510151522.GA43677@troutmask.apl.washington.edu> In-Reply-To: <20180510142452.GA69005@night.db.net> References: <20180509234551.GA39526@troutmask.apl.washington.edu> <CALH631=DK=k2jfOqnQ0OeYCwZG0XQwqq1pjPYTH_=f8xmYDvjw@mail.gmail.com> <20180510142452.GA69005@night.db.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 10, 2018 at 10:24:52AM -0400, Diane Bruce wrote: > On Thu, May 10, 2018 at 10:46:31AM +0300, Gleb Popov wrote: > > On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > In review PR 228007, it came to my attention some individuals are > > > mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD > > > issue". See > > Indeed. I've tried to make it clear it is a name conflict with libgcc > in my own bug reports on the subject. > > > > > > > https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html > > > > > > The problem can be summarized by the following > ... > > > gfortran7 is installed from ports/lang/gcc7. This is not > > > a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. > > > > > > Specifically, there is a shared library name clash. > > > > > > % ldconfig -r | grep gcc_ > > > 6:-lgcc_s.1 => /lib/libgcc_s.so.1 > > > 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 > > Yep. > See https://wiki.freebsd.org/libgcc%20problem > Interesting page. I was aware that in the past you tried working out a solution to the problem. I did not realize you docoumented the issue. A few corrections to your wiki page. 1) The correct spelling of the name of the language is Fortran (with a capital F). It has been the official standard spelling since Fortran 90. 2) You have "... to always support quad math (*8) and ...". Quad precision in gfortran is REAL(16) (the REAL*16 notation is nonstandard). 3) "subsitute" is normally spelled with an extra 't'. :-) > > > So, the runtime loader finds 6 instead of 716, tries to link, > > > fails, and issues an error message. There are a number ways to > > > fix this issue. > > > > > > 1) By far, the best solution would be to stop hijacking the libgcc > > > name in libraries installed on FreeBSD that are not related to > > > actual GCC software. > > Agreed, however this has the side effect of meaning conflicts with libraries > between clang and gcc libs. Notably gfortran and flang use different > conventions for I/O :( > > See http://people.FreeeBSD.org/~db/fortran_libs.txt > Page doesn't appear to exist? If I go to https://people.freebsd.org/homepage.html you're not listed. > > > Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm > > > aware that clang does not work on all archs and the ancient gcc > > > lives on. > > > > > I've argued for this as well and frankly I still think it is the best > solution all around. > > > > 2) Given the expected push back againt solution 1), this solution > > > proposes bumping the library version for /lib/libgcc_s.so.1 from > > > 1 to some larger value, say, 10. It is unlikely that GCC will > > > bump its shared library number anytime soon. GCC bumped it from > > > 0 to 1 some 16 years ago. > > > > > > https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=43316 > > > > > > This solution, however, papers over the general problem with > > > name clashes. > > Yep. I know work is slowly being done to modernise our libgcc already > but the toolchain folks are busy... > > > > > > > 3) This solution is to actually fix the runtime loader. If an error > > > occurs with loading a shared library, then iterate over the entries > > > in the hints file to check to see if another hint would satisfy > > > the linking. Here, instead of issuing the above error, the loader > > > would find entry 716, and load the correct libgcc_s.so.1. > > This breaks if the bad libgcc is already linked. We'd have to rip > out the original bindings at run time, then re-bind to a new libgcc. > I looked at the rtld code months ago. Nasty and silly. > > > > > > > Admittedly, I haven't looked to see how difficult this solution > > > would be. > > Very ;) Just started reading the source code. Don't scare the unwary. :-) -- Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180510151522.GA43677>