From owner-freebsd-ports@FreeBSD.ORG Thu Sep 17 16:45:09 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 BF618106566B for ; Thu, 17 Sep 2009 16:45:09 +0000 (UTC) (envelope-from gerald@pfeifer.com) Received: from vexpert.dbai.tuwien.ac.at (vexpert.dbai.tuwien.ac.at [128.131.111.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7BC9B8FC08 for ; Thu, 17 Sep 2009 16:45:09 +0000 (UTC) Received: from acrux.dbai.tuwien.ac.at (acrux.dbai.tuwien.ac.at [128.131.111.60]) by vexpert.dbai.tuwien.ac.at (Postfix) with ESMTP id B8B311E0B0; Thu, 17 Sep 2009 18:45:06 +0200 (CEST) Received: by acrux.dbai.tuwien.ac.at (Postfix, from userid 1203) id 4DF311005D; Thu, 17 Sep 2009 18:45:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by acrux.dbai.tuwien.ac.at (Postfix) with ESMTP id 3D10110059; Thu, 17 Sep 2009 18:45:10 +0200 (CEST) Date: Thu, 17 Sep 2009 18:45:10 +0200 (CEST) From: Gerald Pfeifer To: ports@FreeBSD.org Message-ID: User-Agent: Alpine 1.99 (LSU 1142 2008-08-13) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Loren James Rittle Subject: Need to use some library path before /usr/lib 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: Thu, 17 Sep 2009 16:45:09 -0000 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