From owner-freebsd-current@freebsd.org Thu May 10 17:22:01 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 1267EFD0DB1; Thu, 10 May 2018 17:22:01 +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 A36B36F021; Thu, 10 May 2018 17:22:00 +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 w4AHLxra046778 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 10 May 2018 10:21:59 -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 w4AHLxef046777; Thu, 10 May 2018 10:21:59 -0700 (PDT) (envelope-from sgk) Date: Thu, 10 May 2018 10:21:59 -0700 From: Steve Kargl To: Tijl Coosemans Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Runtime loader issue Message-ID: <20180510172159.GA46553@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180509234551.GA39526@troutmask.apl.washington.edu> <20180510182151.409b7fb8@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180510182151.409b7fb8@kalimero.tijl.coosemans.org> 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 17:22:01 -0000 On Thu, May 10, 2018 at 06:21:51PM +0200, Tijl Coosemans wrote: > On Wed, 9 May 2018 16:45:51 -0700 Steve Kargl wrote: > > > > 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. > > > > % ls -l /lib/libgcc* /usr/lib/libgcc* > > (trimming lines) > > /lib/libgcc_s.so.1 > > /usr/lib/libgcc.a@ -> libcompiler_rt.a > > /usr/lib/libgcc_eh.a > > /usr/lib/libgcc_eh_p.a > > /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a > > /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 > > > > 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. > > > > 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. > > > > libgcc_s.so implements the _Unwind_* API to handle stack unwinding. This > code is shared between all compilers and languages because the stack can > contain frames from different compilers and languages. So, you cannot > change the name or version of the library. Well, yes one could change the name and/or shared library number. All those other tools would then need to be adapted to look for a renamed or number-bumped library. Yes, painful. > I've been testing the attached patch in combination with the ports tree > patch from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228046. > > The patch makes three changes to /etc/rc.d/ldconfig: > 1) Use 'sort -r' so /usr/local/lib/gcc7 appears before /usr/local/lib/gcc6. > 2) Move hardcoded paths like /lib and /usr/lib to /etc/defaults/rc.conf > so the order relative to other paths can be configured. > 3) Change the order of ldconfig_local_dirs and ldconfig_paths so /lib and > /usr/lib appear last. This brings rc.d/ldconfig in line with compilers > and rtld(1) which also search /lib and /usr/lib last. This appears to work around the problem with libgcc_s.so.1. It would be a welcomed solution to so-called "gfortran's FreeBSD issue", but is does not solve the problem with name clashes. It is possible to have two independent libraries for independent projects where no shuffling of order in hints will work. -- Steve