From owner-freebsd-current@freebsd.org Thu May 10 15:15:33 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 727C6FCD0C6; Thu, 10 May 2018 15:15:33 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0DC3A6EC9A; Thu, 10 May 2018 15:15:32 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w4AFFOJF043970 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 08:15:24 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w4AFFMHh043969; Thu, 10 May 2018 08:15:22 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 08:15:22 -0700 From: Steve Kargl To: Diane Bruce Cc: Gleb Popov <6yearold@gmail.com>, freebsd-hackers , FreeBSD Current , FreeBSD ports list Subject: Re: Runtime loader issue Message-ID: <20180510151522.GA43677@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510142452.GA69005@night.db.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510142452.GA69005@night.db.net> User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 15:15:33 -0000 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