From owner-freebsd-ports@FreeBSD.ORG Wed Feb 22 04:18:32 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 C67BD106566C for ; Wed, 22 Feb 2012 04:18:32 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by mx1.freebsd.org (Postfix) with ESMTP id 5E6F68FC14 for ; Wed, 22 Feb 2012 04:18:31 +0000 (UTC) X-AuditID: 1209190d-b7fbf6d0000008ba-c1-4f44691146a6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 11.28.02234.119644F4; Tue, 21 Feb 2012 23:03:30 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q1M43TwG012147; Tue, 21 Feb 2012 23:03:29 -0500 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q1M43ShC001444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Feb 2012 23:03:29 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id q1M43Rma018844; Tue, 21 Feb 2012 23:03:27 -0500 (EST) Date: Tue, 21 Feb 2012 23:03:27 -0500 (EST) From: Benjamin Kaduk To: Steve Kargl In-Reply-To: <20120221223251.GA23053@troutmask.apl.washington.edu> Message-ID: References: <20120221182850.GA20768@troutmask.apl.washington.edu> <20120221185754.GL55074@deviant.kiev.zoral.com.ua> <20120221194259.GA21185@troutmask.apl.washington.edu> <4F440E8B.9020306@FreeBSD.org> <20120221220053.GA44386@night.db.net> <20120221223251.GA23053@troutmask.apl.washington.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nriuU6eJvsG4tq8WcNx+YLDYdfsto cevuc2YHZo8Zn+azePTunsccwBTFZZOSmpNZllqkb5fAldG96ixzwWaZigWnqhoYd4h1MXJy SAiYSNz4cIcVwhaTuHBvPVsXIxeHkMA+Rommb/uYIZwNjBLHbv9lgXAOMEmcevcVKtPAKNH1 ew0TSD+LgLbEt0c32EFsNgEViZlvNrKB2CICRhKve/rBbGYBK4lzf4+D1QsLmEusnn4VrJ5T wEli/eV7zCA2r4CjxL/Px6EWLGeSaH1xiQUkISqgI7F6/xQWiCJBiZMzn7BADLWUOPfnOtsE RsFZSFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXSy80s0UtNKd3ECApbTkneHYzv DiodYhTgYFTi4S3e6OwvxJpYVlyZe4hRkoNJSZTXIM3FX4gvKT+lMiOxOCO+qDQntfgQowQH s5II7/pfQOW8KYmVValF+TApaQ4WJXFeVa13fkIC6YklqdmpqQWpRTBZGQ4OJQnewgygoYJF qempFWmZOSUIaSYOTpDhPEDDE0FqeIsLEnOLM9Mh8qcYdTk+HnhygVGIJS8/L1VKnNcPpEgA pCijNA9uDizdvGIUB3pLGGIdDzBVwU16BbSECWhJy39HkCUliQgpqQZGf3am0NYzJUu8q7OC 7DWm1ObLzT7erd+u9FdPM+XO/kKjx6dWu8cVfPxie1Pk7bNdxVylym9uLPq/ms1yg/TuJvPt pXzLVz2vrsp/WsvEMnvGJ5MNdz5q3j24OK26LjPCToNR5v16y/8v7Sbff3W07wFDtFyt3LTb z/YwRrMIyUmbHF5f/C9QiaU4I9FQi7moOBEA0zt+5BIDAAA= 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: Wed, 22 Feb 2012 04:18:32 -0000 On Tue, 21 Feb 2012, Steve Kargl wrote: > On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote: >> On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote: >>> On 2012-02-21 20:42, Steve Kargl wrote: >>> ... >>>> 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. >> >> Does -rpath not help ? > > I already mentioned that I can add '-rpath /usr/local/lib/gcc46' > to my various projects. I can also build with -static to avoid > rtld. One can also use LD_LIBRARY_PATH. > > The issue seems to be that lang/gcc will be installed after > system start, and 'ldconfig -m' appends new shared libraries > to the hints file. This means that libraries with the same > name but different locations will be found via the order of the > search path in the hints file, and one gets the wrong library. > That is, with the following > > troutmask:root[256] 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 > > 29 will be found before 723. While I can work around the > issue, lang/gcc is used by a rather large boatload of ports > during the building process and I suspect that a large > number of FreeBSD users use lang/gcc for their everyday > compiler. The question is how do we, the FreeBSD project, > deal with this issue, so that the general user base does not > get hit with it. I think there is perhaps a little more to this issue of multiple (incompatible) copies of a library with the same name being installed, e.g. libcom_err in /usr/lib/libcom_err.so and /usr/local/lib/libcom_err.so. An application using the library must #include to get the library prototypes, but the preprocessor puts the standard include search path /usr/include at the end of the search list, even if it is specified explicitly on the command line, unless -nostdinc is passed. So this will prefer the header from ports in the absence of evil trickery. I was pounding my head against this a couple years ago, so my memory is not quite fresh, but I think that I could convince the compile-time link step to use either version of the library with the appropriate ordering of -L arguments (but I am in trouble if I want libkrb5.so from ports and libcom_err.so from base!). In any case, the dynamic linker will search the default search path *first*, preferring the copy of the library from the base system. After pounding my head against the issue for a while I concluded that I had no option other than to use -rpath (but alas I ran out of time for that particular project and never finished). It is definitely an ugly situation and I have no good answers. It would be nice to not have to specify every detail of what should be happening, though. > > There are a few solutions: > 1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to > be scanned before /lib and /usr/lib. > 2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned > for /lib and /usr/lib. > 3) Add a new option to ldconfig to prepend new libraries to > the hints files and fix the ports to use this option instead > of -m. > 4) Suggestions from people that are brighter than I. How would things break if we made everything in the base system specify -rpath of /lib and /usr/lib as appropriate, and then put the ports versions first in the default search path? -Ben Kaduk