From owner-freebsd-ports@FreeBSD.ORG Tue Feb 21 19:43:00 2012 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0883E106564A; Tue, 21 Feb 2012 19:43:00 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id BDC688FC08; Tue, 21 Feb 2012 19:42:59 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id q1LJgxjB021359; Tue, 21 Feb 2012 11:42:59 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id q1LJgxx9021358; Tue, 21 Feb 2012 11:42:59 -0800 (PST) (envelope-from sgk) Date: Tue, 21 Feb 2012 11:42:59 -0800 From: Steve Kargl To: Konstantin Belousov Message-ID: <20120221194259.GA21185@troutmask.apl.washington.edu> References: <20120221182850.GA20768@troutmask.apl.washington.edu> <20120221185754.GL55074@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120221185754.GL55074@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-ports@freebsd.org Subject: Re: rtld or lang/gcc cannot find libgcc_s.so.1 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:43:00 -0000 On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: > On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: > > > > troutmask:kargl[210] halfspace > > /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace > > not foundtroutmask:kargl[211] > > > > (Note, the annoying absense of a newline character after the error > > message, which is a completely different issue.) > > > > I see this problem on both freebsd-i386 and freebsd-amd64. > > > > troutmask:kargl[212] ldd ~/bin/halfspace > > /home/kargl/bin/halfspace: > > liblapack.so.4 => /usr/local/lib/liblapack.so.4 (0x2008c3000) > > libblas.so.2 => /usr/local/lib/libblas.so.2 (0x201463000) > > libgfortran.so.3 => /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) > > libm.so.5 => /lib/libm.so.5 (0x201a70000) > > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201c95000) > > libquadmath.so.0 => /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) > > libc.so.7 => /lib/libc.so.7 (0x2020d6000) > > troutmask:kargl[212] ldconfig -r | grep libgcc_s > > 29:-lgcc_s.1 => /lib/libgcc_s.so.1 > > 723:-lgcc_s.1 => /usr/local/lib/gcc46/libgcc_s.so.1 > > > > So, it appears that rtld is finding the wrong libgcc_s.so.1 or > > the lang/gcc port is no longer providing sufficient information > > for rtld to choose the correct library. > > > > I have reverted revisions 230784, 299768, and 229508 (and > > various combinitions of these revisions) from rtld-elf. The > > result does not change the above error. > > > > I can work around the problem by specifying -static during > > the building of my programs. Or, I can work around the > > problem by *explicitly* adding '-rpath /usr/local/lib' to the > > command line, which I have never had to do. > > > I highly suspect that you just happen to not need a symbol from the > newest namespace before. > > The thing to look first is the library search path in the ld.so hints, > which is output at the second line of ldconfig -r. I think that you have > /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed > by the numeration of the two instances of gcc_s above. Either change > the config, or use -rpath. AFAIR, ldconfig -m adds the directory > at the end of the search list. Yes, /lib comes before /usr/local/lib/gcc46. I suppose that this is a heads up for gerald@. lang/gcc is used by the ports collections to build a large number of other ports, so others are likely to hit this issue. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. -- Steve