Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 24 Feb 2001 12:50:44 -0800
From:      Jordan Hubbard <jkh@osd.bsdi.com>
To:        brooks@one-eyed-alien.net
Cc:        tlambert@primenet.com, marcel@cup.hp.com, jhb@FreeBSD.ORG, arch@FreeBSD.ORG
Subject:   Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand]
Message-ID:  <20010224125044P.jkh@osd.bsdi.com>
In-Reply-To: <20010223162903.A7882@Odin.AC.HMC.Edu>
References:  <3A96F984.7233C733@cup.hp.com> <200102240016.RAA02409@usr05.primenet.com> <20010223162903.A7882@Odin.AC.HMC.Edu>

next in thread | previous in thread | raw e-mail | index | archive | help
From: Brooks Davis <brooks@one-eyed-alien.net>
Subject: Re: ELF, OS and ABI [was: Re: sysctl kern.fallback_elf_brand]
Date: Fri, 23 Feb 2001 16:29:03 -0800

> Darwin uses this or similar support.  The people from Apple has stated
> that they want fat binary support in openpackages.  It's also been

I might also note that you don't need to play ELF games to get "fat
binary support" in a package system, the idea of a permuted name space
inside a package being something I've suggested several times in our
PackageToolsNG discussions.

Basically, the idea is that if you have a random-access package
archive format (or even if you don't, it just being a little more
painful then) then you can frob the package directory information in
such a way that you encode names and property information into each
physical directory entry, similar to the way C++ mangles type/function
information into a global symbol space.  That way a "fat package" for,
say, GNU bash might have a directory which looks something like this:

bin/bash@arch=i386
bin/bash@arch=alpha
man/man1/bash.1.gz@*
info/bash.info@*

Where, in this highly contrived example, we assume that everything
following an un-escaped @ is the start of the property list
information which has to be matched in order for that item to be
extracted under its real name.  Things with *'s in the example match
all extraction criteria.  Obviously, one could further extend this to
have version-specific properties in order to support multiple versions
(perhaps one "stable" and one "development") in a package or
option-specific properties, like "no man pages please".  A canonical
base set of property names and values would obviously have to be
agreed upon in order for this to work, but it's a lot easier and far
more flexible than using ELF binaries with multiple personalities. :)

- Jordan

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010224125044P.jkh>