From owner-freebsd-ports@freebsd.org Sun Aug 21 06:08:02 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 B0C40BC078C for ; Sun, 21 Aug 2016 06:08:02 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [150.101.137.129]) by mx1.freebsd.org (Postfix) with ESMTP id 4D06F1944 for ; Sun, 21 Aug 2016 06:08:01 +0000 (UTC) (envelope-from FreeBSD@shaneware.biz) Received: from ppp14-2-4-72.lns21.adl2.internode.on.net (HELO leader.local) ([14.2.4.72]) by ipmail06.adl2.internode.on.net with ESMTP; 21 Aug 2016 15:37:59 +0930 Subject: Re: Problems with out libgcc_s.so in base To: Diane Bruce 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> <20160820120056.GA1475@night.db.net> Cc: freebsd-ports@freebsd.org From: Shane Ambler Message-ID: Date: Sun, 21 Aug 2016 15:37:58 +0930 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160820120056.GA1475@night.db.net> Content-Type: text/plain; charset=utf-8; format=flowed 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: Sun, 21 Aug 2016 06:08:02 -0000 On 20/08/2016 21:30, Diane Bruce wrote: > 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 Actually the problem is going the other way. A port gets compiled and linked against the newer libs but at run time it finds the base system lib first and loads that which doesn't support the binary that is being run. If the gcc6 libgcc_s was always installed and found first then we wouldn't have this problem. I first found this issue trying to import numpy into blender. As blender had started and was using the base libgcc_s, when I tried to import numpy that needed the newer libgcc_s for it's fortran code it failed. I discovered that setting LD_LIBRARY_PATH in the environment when starting blender got it to load the newer libgcc_s which then worked when importing numpy, so I've been happy doing that for a couple of years. I have seen the same thing were a python module has brought in the base libgcc_s before numpy which needed the newer one. The dynamic loading of python modules seems to be the only time I have seen this. Either changing the import order or LD_LIBRARY_PATH to get the newer lib loaded the first time has solved the issue. So one solution could be to copy the newer libgcc_s into /lib but the newer library won't get added to base as it contains GPLv3 code. Maybe remove /lib/libgcc_s.so to force the search for a newer version. While bug reports have lead to other things, I think the solution might be to configure/patch ld to get it searching paths to find the newer version first. libgcc_s would be such a common case that we could have a permanent ld setting in base to always find a newer libgcc_s before the base version. I haven't been bitten enough to have looked at this. -- FreeBSD - the place to B...Software Developing Shane Ambler