From owner-freebsd-ports@freebsd.org Thu May 10 14:25:01 2018 Return-Path: Delivered-To: freebsd-ports@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 938DDFCB0A2; Thu, 10 May 2018 14:25:01 +0000 (UTC) (envelope-from db@db.net) Received: from artemis.db.net (artemis.db.net [45.32.229.41]) by mx1.freebsd.org (Postfix) with ESMTP id 334468A077; Thu, 10 May 2018 14:25:00 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by artemis.db.net (Postfix) with ESMTP id 7DB3D1023A; Thu, 10 May 2018 14:24:53 +0000 (UTC) Received: by night.db.net (Postfix, from userid 1000) id C788E39813; Thu, 10 May 2018 10:24:52 -0400 (EDT) Date: Thu, 10 May 2018 10:24:52 -0400 From: Diane Bruce To: Gleb Popov <6yearold@gmail.com> Cc: sgk@troutmask.apl.washington.edu, freebsd-hackers , FreeBSD Current , FreeBSD ports list Subject: Re: Runtime loader issue Message-ID: <20180510142452.GA69005@night.db.net> References: <20180509234551.GA39526@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.5 (2018-04-13) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2018 14:25:01 -0000 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 > > > > 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 > > > > 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 ;) > > > > 4) Bump the shared library number of the individual ports. As a proof > > of concept, I've done this with ports/lang/gcc6. > > ... > > > > Finally, can people stop referring to the above error as > > "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. Yes, please. I tracked it down to libgcc months ago, made my findings generally available and yet people are still calling it a libgfortran problem. > > > > Our libgcc also lacks some functionality compared to the original one: > https://reviews.freebsd.org/D11482 Yes. Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db