From owner-freebsd-ports@freebsd.org Sat Aug 20 12:01:05 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 B873DBBFB38 for ; Sat, 20 Aug 2016 12:01:05 +0000 (UTC) (envelope-from db@db.net) Received: from diana.db.net (diana.db.net [66.113.102.10]) by mx1.freebsd.org (Postfix) with ESMTP id A60441873 for ; Sat, 20 Aug 2016 12:01:05 +0000 (UTC) (envelope-from db@db.net) Received: from night.db.net (localhost [127.0.0.1]) by diana.db.net (Postfix) with ESMTP id 954352AA49F; Sat, 20 Aug 2016 06:00:14 -0600 (MDT) Received: by night.db.net (Postfix, from userid 1000) id 19A3F1CDE4; Sat, 20 Aug 2016 08:00:57 -0400 (EDT) Date: Sat, 20 Aug 2016 08:00:56 -0400 From: Diane Bruce To: Shane Ambler Cc: freebsd-ports@freebsd.org Subject: Re: Problems with out libgcc_s.so in base Message-ID: <20160820120056.GA1475@night.db.net> References: <20160814230351.GA10587@troutmask.apl.washington.edu> <20160814233430.GA35872@night.db.net> <20160817211710.GA59205@troutmask.apl.washington.edu> <20160818111521.7f79b9f8@kalimero.tijl.coosemans.org> <20160819011432.6f2eadbd@kalimero.tijl.coosemans.org> <20160819004304.GA94021@troutmask.apl.washington.edu> <9663a390-080e-462d-84d7-2a27987b83e5@ShaneWare.Biz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9663a390-080e-462d-84d7-2a27987b83e5@ShaneWare.Biz> User-Agent: Mutt/1.6.1 (2016-04-27) 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: Sat, 20 Aug 2016 12:01:05 -0000 On Sat, Aug 20, 2016 at 03:04:44PM +0930, Shane Ambler wrote: > On 19/08/2016 10:13, Steven G. Kargl wrote: ... > You should find that all newer copies of libgcc_s contain compatibility > support for binaries that were linked to earlier versions. > Indeed. And the version masquerading as a GNU libgcc_s in base does the same thing. Two problems: our base libgcc_s only covers version up to GCC_4.2.0 and there is a name conflict on the library name with libgcc_s from the gnu compiler. Hence if a program links against base libgcc_s first then requires libgfortran which itself requires support for above GCC_4.2.0, the program fails. OR Whenever a program requires support that is missing on the platform it is running on from our libgcc_s, it will fail. There are numerous PR's on this which all have the common problem of linking with a libgcc_s that does not support > GCC_4.2.0 Diane -- - db@FreeBSD.org db@db.net http://www.db.net/~db