From owner-freebsd-questions@FreeBSD.ORG Fri Oct 24 13:09:36 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2313B106566B for ; Fri, 24 Oct 2008 13:09:36 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id E6D058FC0C for ; Fri, 24 Oct 2008 13:09:35 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so801765rvf.43 for ; Fri, 24 Oct 2008 06:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=GJmd5MdXalSuuur/PWML/yEWsqt/lmhnr2Vi/pkqOhI=; b=Bp/q+6oDkC9kwwtLwIt+oYv9JRMgy7b9z0JlfKfCrtyBThNnv93EEcD+smRzrq8sa9 ScDRXAslcRoJkVzTR7cUi0m11NGPSX4rVYO+2NWKi7lo5dYrVU3CC3mZRhNv4zJnHgbv ZNRRDYEqghiyXoIrKXKO63cgKm+kUwLYNPNxw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aRjJQ/PGpD3n7fjvQmqzm5GJr/YT1miC5uOGvq698lTAfxYR0vCiXmcqtDhqODXj8Q Q6l4CBwA4Ges4jo4wJZdcQAMUSlpjVpi6WRZ6Gjibaon7ARxWJEV5Jglx6KbDN0YcGLO aiBq3qphZuGOgnjoWK7C3oRFtlPdiClZjfZCs= Received: by 10.141.2.18 with SMTP id e18mr1168103rvi.90.1224853775385; Fri, 24 Oct 2008 06:09:35 -0700 (PDT) Received: by 10.141.43.14 with HTTP; Fri, 24 Oct 2008 06:09:35 -0700 (PDT) Message-ID: <3c0b01820810240609g402e4947m762f59c0ddd434ea@mail.gmail.com> Date: Fri, 24 Oct 2008 09:09:35 -0400 From: "Alexander Sack" To: "Peter Jeremy" In-Reply-To: <20081024125059.GE1137@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3c0b01820810231731s1b4d4659j7d1df8bf4abb229c@mail.gmail.com> <20081024104232.X21603@wojtek.tensor.gdynia.pl> <20081024125059.GE1137@server.vk2pj.dyndns.org> Cc: Wojciech Puchar , freebsd-questions@freebsd.org Subject: Re: Why does adding /usr/lib32 to LD_LIBRARY_PATH break 64-bit binaries? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Oct 2008 13:09:36 -0000 On Fri, Oct 24, 2008 at 8:50 AM, Peter Jeremy wrote: > On 2008-Oct-24 10:43:04 +0200, Wojciech Puchar wrote: >>> 6.1-RELEASE-amd64 machine. If I add /usr/lib32 to my LD_LIBRARY_PATH >>> it breaks all of my binaries on my 64-bit machine. >> >>what do you expect else? > > Well, the rtld should be smart enough to recognize 32-bit .so's and > skip them when binding a 64-bit executable. Whilst having /usr/lib32 > in LD_LIBRARY_PATH doesn't make sense from a solely FreeBSD perspective, > I have done similar things when writing cross-platform scripts (to > avoid having to use platform-dependent code). > >>this will make system trying to bind 32-bit libs to 64-bit program. it >>can't work > > rtld shouldn't attempt to bind 32-bit libs to 64-bit programs. Bingo! I don't care what the LD_LIBRARY_PATH is, a 64-bit binary should NEVER attempt to load a 32-bit library (at least by default). If anything, rtld should just exit with can't find library exception. What its doing now in my book is just wrong in everyway. The name of the shared object is no longer enough to verify a match, it also needs to check the arch bits as well. I agree with everyone on this list that for FreeBSD, the gcc toolset initialization should always contain /lib (and in fact I am going further and saying that al *NIX platforms should probably always check /lib since its the default and its there during bootup (that was a good point btw)). I think the issue has been cross platform builds and the way Linux has it organized. I have submitted a patch to add /lib back to the Boost folks but I still want to understand this behavior on FreeBSD - what am I missing? Final note, I thought that /usr/lib would have the major number versions linked just like /usr/lib32 so the above would just work. Right now the issue is libutil.so.5 isn't found not because /lib isn't in the LD_LIBRARY_PATH, i.e If I make a symlink in /usr/lib just like the /usr/lib32 file structure, it all just works. I was just saying above that I was wondering why major numbers aren't actually available as links in /usr/lib like they are in /usr/lib32. -aps