From owner-freebsd-current@FreeBSD.ORG Wed Feb 22 05:11:15 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 556E51065675 for ; Wed, 22 Feb 2012 05:11:15 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 276318FC08 for ; Wed, 22 Feb 2012 05:11:14 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id q1M5BE49095482; Wed, 22 Feb 2012 05:11:14 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.119] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 7fmv9ezen3hqe9xu3fqq65dqwe; Wed, 22 Feb 2012 05:11:13 +0000 (UTC) (envelope-from tim@kientzle.com) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Tim Kientzle In-Reply-To: Date: Tue, 21 Feb 2012 21:11:13 -0800 Content-Transfer-Encoding: 7bit Message-Id: <5C146DC6-264B-43A9-9234-9E03315F3D33@kientzle.com> 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> To: Daniel Eischen X-Mailer: Apple Mail (2.1257) Cc: freebsd-current FreeBSD , freebsd-ports@freebsd.org, Steve Kargl Subject: Re: rtld or lang/gcc cannot find libgcc_s.so.1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 05:11:15 -0000 On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: > On Tue, 21 Feb 2012, Steve Kargl wrote: > >> 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. > > You don't want system binaries that want /lib/libgcc_s.so.1 > to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't > your option 3 do that? Why not? Would it cause problems? Is libgcc from GCC 4.6 incompatible with /lib/libgcc? If I understand correctly, the libgcc in base is pretty stripped down compared to "regular" libgcc, because most of that stuff is in our libc instead. So if there were compatibility problems, I'd expect those to show up when GCC 4.6 linked programs against /usr/local/.../libgcc and /lib/libc. Tim