From owner-freebsd-ports@FreeBSD.ORG Fri Sep 18 01:44:00 2009 Return-Path: Delivered-To: ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1979106566B for ; Fri, 18 Sep 2009 01:44:00 +0000 (UTC) (envelope-from jasonh@DataIX.net) Received: from www6.pairlite.com (www6.pairlite.com [64.130.10.16]) by mx1.freebsd.org (Postfix) with ESMTP id AD0E38FC0A for ; Fri, 18 Sep 2009 01:44:00 +0000 (UTC) Received: from firewall.5p.local (unknown [99.190.84.178]) by www6.pairlite.com (Postfix) with ESMTP id AD02DB82A; Thu, 17 Sep 2009 21:43:59 -0400 (EDT) Date: Thu, 17 Sep 2009 21:43:58 -0400 From: "Jason J. Hellenthal" To: "Jason J. Hellenthal" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-OpenPGP-Key-ID: 0x691411AC X-OpenPGP-Key-Fingerprint: 6F56 3B10 D8AD 1D33 96E7 5946 E3B6 2768 6914 11AC MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ports@freebsd.org, Loren James Rittle , Gerald Pfeifer Subject: Re: Need to use some library path before /usr/lib X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Jason J. Hellenthal" List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 01:44:00 -0000 On Thu, 17 Sep 2009 21:24 -0000, jasonh wrote: > On Thu, 17 Sep 2009 12:45 -0000, gerald wrote: > >> Building some (Fortran) applications with lang/gcc44 it turns out we get >> weird failures upon startup which look like: >> >> /libexec/ld-elf.so.1: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.11 >> required by ./gendoc not found >> >> What is happening here is that lang/gcc44 lays down >> /usr/local/lib/gcc44/libstdc++.so.6 >> and puts /usr/local/lib/gcc44 into USE_LDCONFIG. Alas the system then >> finds and uses /usr/lib/libstdc++.so.6 from our aging system compiler >> instead. >> >> Now, both libraries share the same name/version because these libraries, >> like also (and especially) libgcc_s.so.1 because new versions are drop >> ins for older ones, but not the other way round. >> >> How can we address this? >> >> Updating the old, unsupported by upstream system compiler has >> been ruled out historically, and does not look like an option (and also >> would not help older versions of FreeBSD). >> >> Use -rpath, somehow, by changing the configuration of the >> lang/gcc44 ports? That sucks in that it will break updates to newer >> versions of GCC. >> >> Set up ldconfig such that /usr/local/lib/gcc44 comes before >> /usr/lib? >> >> Anything else? Any pointers on how to best implement an ordering of >> search paths for ldconfig (or rpath, if that is the best of options)? >> >> Gerald >> >> > > Would it be possible to just libmap.conf gcc44 and friends just for that lib > and the programs it builds. I know this is not such a great solution but for > the mean time it may be a relevant answer. > Something like the following. [/usr/local/bin/] libstdc++.so /usr/local/lib/gcc44/libstdc++.so libstdc++.so.6 /usr/local/lib/gcc44/libstdc++.so.6 On a second note. It would be real nice if the install of a second/third compiler would get installed into its own directory rather than placing executables in /usr/local/bin/ place them /usr/local/lib/gcc44/bin and create the symlinks to them. This would at least help the libmap issue and gcc44 for several ports (just building). Now for a port running (octave as example) have that port spam libmap.conf with the proper configuration for just that port the same way perl does to make.conf. -- Jason J. Hellenthal http://www.DataIX.net/ jasonh@DataIX.net 0x691411AC - (2^(N-1))