From owner-freebsd-ports@freebsd.org Mon Aug 22 08:00:15 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 51709BC1D57 for ; Mon, 22 Aug 2016 08:00:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:7b8:3a7:1:2d0:b7ff:fea0:8c26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1AEDA124B for ; Mon, 22 Aug 2016 08:00:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:7b8:3a7::cdc4:3bd1:3327:90c9] (unknown [IPv6:2001:7b8:3a7:0:cdc4:3bd1:3327:90c9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BE44B39B44; Mon, 22 Aug 2016 10:00:11 +0200 (CEST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Problems with out libgcc_s.so in base From: Dimitry Andric In-Reply-To: <6f6a2c65-216a-3d7e-825f-222a06428f60@gmx.de> Date: Mon, 22 Aug 2016 10:00:11 +0200 Cc: freebsd-ports@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <0CA458FB-AF10-4765-9BE1-886A710BAA30@FreeBSD.org> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <6f6a2c65-216a-3d7e-825f-222a06428f60@gmx.de> To: Matthias Andree X-Mailer: Apple Mail (2.3124) 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: Mon, 22 Aug 2016 08:00:15 -0000 On 22 Aug 2016, at 08:26, Matthias Andree wrote: > > Am 18.08.2016 um 14:48 schrieb Dimitry Andric: >> 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 > > This in itself - to me - seems to be the actual problem, how do > different versions of the library the same major version? The gcc folks use symbol versioning, see: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html This works incrementally, so libgcc from gcc N is backwards compatible with all previous libgcc's from gcc < N. Not the other way around, of course. On Linux systems, there are no compatibility problems as we have seen them, because you simply install the most recent libgcc into /lib, and all applications will use that. Older applications will find their older ABI through symbol versioning. However, even on a Linux system you could get into trouble if you would compile and install a newer version of gcc than the system's default. Applications linked with that newer version would possibly require a newer libgcc ABI, and you would have the same problem that we have now. -Dimitry