From owner-freebsd-ports@freebsd.org Wed May 9 23:45:59 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 A63A7FCF1ED; Wed, 9 May 2018 23:45:59 +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 3DD3572828; Wed, 9 May 2018 23:45:59 +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 w49NjqaE039550 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 9 May 2018 16:45:52 -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 w49Njp0F039549; Wed, 9 May 2018 16:45:51 -0700 (PDT) (envelope-from sgk) Date: Wed, 9 May 2018 16:45:51 -0700 From: Steve Kargl To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org, freebsd-ports@freebsd.org Subject: Runtime loader issue Message-ID: <20180509234551.GA39526@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) 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: Wed, 09 May 2018 23:46:00 -0000 In review PR 228007, it came to my attention some individuals are mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD issue". See https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html The problem can be summarized by the following % gfortran7 -o z h.f90 % ./z /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ /usr/local/lib/gcc7/libgfortran.so.4 not found 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 % ldd z z: libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x200a17000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) libc.so.7 => /lib/libc.so.7 (0x200ca3000) 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. 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. Admittedly, I haven't looked to see how difficult this solution would be. 4) Bump the shared library number of the individual ports. As a proof of concept, I've done this with ports/lang/gcc6. % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc --- libgcc/config/t-slibgcc.orig 2018-05-08 12:47:42.334495000 -0700 +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 @@ -20,7 +20,7 @@ SHLIB_EXT = .so SHLIB_SOLINK = @shlib_base_name@.so -SHLIB_SOVERSION = 1 +SHLIB_SOVERSION = 2 SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) SHLIB_MAP = @shlib_map_file@ SHLIB_OBJS = @shlib_objs@ % 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 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 % gfortran6 -o z h.f90 % ./z hello % ldd z z: libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x20096c000) libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a0000) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) libc.so.7 => /lib/libc.so.7 (0x200df7000) This works for this particular name conflict. Hopefully, FreeBSD never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, however, introduces an incompatibility with what is actually distributed by GCC. Finally, can people stop referring to the above error as "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. -- Steve