From owner-freebsd-arch@FreeBSD.ORG Fri Feb 13 21:11:10 2009 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2F431065672 for ; Fri, 13 Feb 2009 21:11:10 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 5CB6B8FC16 for ; Fri, 13 Feb 2009 21:11:10 +0000 (UTC) (envelope-from heliocentric@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so805204yxl.13 for ; Fri, 13 Feb 2009 13:11:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=qPW+Mzq9QgVGzkZ5ffR8CYXdnxMqM1vYiQBdoTDOYog=; b=b/lR8TBO11bkG5dopSEJBWKPhK9VgjtRn/mN/ZJ6TrDzpqjz0oxeUNVF0CPXTinmSR KChUJeGBtPD8DMUAQWIGhlEyUF/oOIAUYzrcCqQoyyDVzRfSEh7HjBej5Mfddysbs7ZX tlt7l04MT6Bgu4LV+iVJ0LSNvearsE2L+lGT4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=l7OP4kBrdEBZzdCVTIvvcYlwKBWjLL+kxlXl3nGKqELut45FF6PImf9cuM8elQjruY u7W0ITAL06oh+QUAUAX4ziEPYxuGcU6GC3cTN9FzZOXL51o+Vh+X6XQFAma0KYURFkw0 h0BtdIp1YDrXGM9yhR39P7ZaqD61iRn5nEHHY= MIME-Version: 1.0 Sender: heliocentric@gmail.com Received: by 10.90.65.14 with SMTP id n14mr1438065aga.4.1234558087415; Fri, 13 Feb 2009 12:48:07 -0800 (PST) In-Reply-To: <20090213002141.GA47689@lor.one-eyed-alien.net> References: <20090212201101.GI2723@deviant.kiev.zoral.com.ua> <200902122119.n1CLJOmI092041@ambrisko.com> <20090213001935.GA21752@zim.MIT.EDU> <20090213002141.GA47689@lor.one-eyed-alien.net> Date: Fri, 13 Feb 2009 15:48:07 -0500 X-Google-Sender-Auth: 267cef2be2367eb7 Message-ID: From: Dylan Cochran To: Doug Ambrisko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arch@freebsd.org Subject: Re: rtld enhancement to add osversion sub-directory search X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 21:11:10 -0000 On Thu, Feb 12, 2009 at 7:21 PM, Brooks Davis wrote: > On Thu, Feb 12, 2009 at 07:19:35PM -0500, David Schultz wrote: >> On Thu, Feb 12, 2009, Doug Ambrisko wrote: >> > Kostik Belousov writes: >> > | There is a popular feature, unfortunately, not supported by FreeBSD >> > | ld.so, called Dynamic String Tokens, see >> > | http://docs.sun.com/app/docs/doc/817-1984/appendixc-4?l=en&a=view >> > | >> > | I have almost abandoned patch that adds support for $ORIGIN, $OSREL, >> > | $OSNAME, and $PLATFORM. Quite amazingly, it merged with today CURRENT >> > | without serious conflicts. >> > | http://people.freebsd.org/~kib/misc/rtld_locks.4.patch >> > >> > That is an interesting feature, however, it almost seems backwards for >> > me if I understand it correctly. I need old binaries to find the library >> > it was built with and not new ones based on the base OS. The plus that >> > I see with their feature is for a library that has been optimized for a >> > specific type of CPU etc. >> >> The Solaris rtld features are very useful when you want to >> export a volume with a bunch of apps over NFS, and the clients are >> running different releases or different architectures. It can >> probably also solve your problem if you bother to place different >> library versions in different directories and set your library >> path appropriately. >> >> As you mention, it's also useful for optimization; people who >> install binary releases don't need to tolerate libraries that have >> been compiled to run on an 80486 DX. > > In principle this would allow numeric libraries like ATLAS to be > compiled for all the microarchitectures on a heterogeneous cluster. > That could have a major impact on some applications. > > -- Brooks > I'm interested in this work as well. Right now I have all the infrastructure in place to generate images with multiple freebsd kernel versions and architectures, but it relies on a statically linked binary to nullfs mount the right /lib and /libexec into place, depending upon which kernel is booted. So anything that could get rid of a hack like that would be very welcome indeed. :)