From owner-freebsd-ports@freebsd.org Thu Aug 18 23:15:48 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49DC7BBF4BF; Thu, 18 Aug 2016 23:15:48 +0000 (UTC) (envelope-from tijl@freebsd.org) Received: from mailrelay110.isp.belgacom.be (mailrelay110.isp.belgacom.be [195.238.20.137]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (Client CN "relay.skynet.be", Issuer "GlobalSign Organization Validation CA - SHA256 - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 494B11EC1; Thu, 18 Aug 2016 23:15:46 +0000 (UTC) (envelope-from tijl@freebsd.org) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2BsCADTQLZX/9SdgG1eg0RJDW0PuWggg?= =?us-ascii?q?jaDRwKBczwRAgEBAQEBAQFeJ4ReAQEEATocIwULCw4KCSUPKh4GE4gpDAq9LAE?= =?us-ascii?q?BAQEBAQEDAQEBAQEBIYp3ihsFjh2LKIYggn+FdXGOY0iLdYN4NCCDfDoyAYcsA?= =?us-ascii?q?QEB?= Received: from 212.157-128-109.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([109.128.157.212]) by relay.skynet.be with ESMTP; 19 Aug 2016 01:14:34 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.15.2/8.15.2) with ESMTP id u7INEX7F040477; Fri, 19 Aug 2016 01:14:33 +0200 (CEST) (envelope-from tijl@FreeBSD.org) Date: Fri, 19 Aug 2016 01:14:32 +0200 From: Tijl Coosemans To: Dimitry Andric Cc: Steve Kargl , freebsd-toolchain@freebsd.org, freebsd-ports@freebsd.org, kargl@uw.edu Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> In-Reply-To: References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 23:15:48 -0000 On Thu, 18 Aug 2016 14:48:28 +0200 Dimitry Andric wrote: > On 18 Aug 2016, at 11:15, Tijl Coosemans wrote: >> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl wrote: >>> % gfortran6 -o z foo.f90 && ./z >>> /lib/libgcc_s.so.1: version GCC_4.6.0 required by \ >>> /usr/local/lib/gcc6/libgfortran.so.3 not found >>> % ldconfig -r | grep libgcc >>> 6:-lgcc_s.1 => /lib/libgcc_s.so.1 >>> 735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1 >>> >>> Clearly, ldd is looking for 735 but finds 6. If the lang/gcc6 could >>> be convinced to build, install, and use libgcc_s6.so.1, then the >>> problem is solved without a wrapper. >> >> In this case the real cause of the problem is that compilers and linkers >> search /lib and /usr/lib last and ldconfig searches them first. Renaming >> the library is just a hack around that. > > Well, even if you would adjust the compilers and linkers to look in > /usr/local/lib first, No, I wanted to change /etc/rc.d/ldconfig to put /lib and /usr/lib last. That would match base ld(1) so anything that links successfully at compile-time will also link successfully at run-time (if there are no other search order mismatches leading to conflicts). But, this means that in case of a name conflict between base and ports, the ports provided library is assumed to be the right one. I'm not 100% sure this is smart. Usually the ports version of a library is more recent and if the name is the same it should be backward compatible, but if that's not the case (older or not compatible) base utilities may fail to run (like ./z in the example above) and that's maybe worse than ports or locally built programs failing. > how would you solve the problem of having > multiple, possibly incompatible versions of the same library in > different directories? > > For example, on one of my systems, I now have these: > > /usr/local/lib/gcc47/libgcc_s.so.1 > /usr/local/lib/gcc48/libgcc_s.so.1 > /usr/local/lib/gcc49/libgcc_s.so.1 > /usr/local/lib/gcc5/libgcc_s.so.1 > /usr/local/lib/gcc6/libgcc_s.so.1 > /usr/local/lib/gcc7/libgcc_s.so.1 > > So which one are you going to put at the front of the path? The gcc7 > version? If you are lucky that one is backwards compatible with all the > previous ones, but still I would like it much better if a program > compiled by, say, gcc5 was linked *explicitly* against the gcc5 version > of libgcc_s.so. > > Steve's proposed scheme solves that quite nicely, in my opinion. The > problem is only in the details, as usual. There will be many configure > scripts and libtool-like utilities out there, that assume libgcc must be > linked using -lgcc_s, not -lgcc_s$VERSION. This is a separate problem that has been discussed many times before. The ports tree adds -Wl,-rpath to *FLAGS in several places to choose a library. I now noticed there is a FAQ about this at https://gcc.gnu.org/faq.html#rpath. It gives some suggestions including creating wrapper scripts, but they wouldn't work when code is compiled with gfortran but linked with Clang cc/c++. The only thing that works in this case is -Wl,-rpath. Another option would be to create a port that installs a recent version of libgcc in /usr/local/lib and let the gcc ports use that instead of their own copy.