rtld enhancement to add osversion sub-directory search

[Dylan Cochran]

On Thu, Feb 12, 2009 at 7:21 PM, Brooks Davis <brooks at freebsd.org> 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. :)