[Openmcl-devel] universal binaries

[Gary Byers]

On Thu, 16 Apr 2009, Alexander Repenning wrote:

> Terje's approach with the shell script may work but I would not like the idea 
> of the finder not recognizing the universal binary as such.

Great idea.

>
> We are only using the IDE versions of CCL with the large, merged kernel + 
> heap "d<architecture>cl" files. Could the Cocoa/IDE version  be lipoed 
> together given that there would not be the problem with finding the right 
> image file? If so, what would be the proper way to use lipo to achieve this?
>

There is no way to use lipo to make CCL heap images suddenly become
multi-architecture, regardless of whether those images are merged into
the same file as a (lipo'ed or not) kernel.  (Making heap images
multi-architecture involves treating them as archives whose members
are architecture-specific images, in much the same way that fat
executable files and libraries are archives whose members are
architecture-specific executable files and libraries.)

If you just want the effect of having the Finder and other tools
recognize a .app as being multiarchitecture (and don't really
care about whether everything's packed into a single file or not),
then it's probably simple for the kernel to recognize that it's
a fat binary and to change the rule used to derive the default
image name from the kernel name. (That rule is "apppend '.image'
to the kernel pathname, and of course that can only work in
the multi-arch case when .image files support multiple architectures.)

If the kernel can basically look at itself and see that the executable
file has a fat header and signature, then that rule could change to
"append a dot and an architecture identifier to the kernel pathname"
An app bundle might have a directory layout like:

Foo.app/
  Contents/
   Resources/
     ...
   MacOS/
    Foo  < multi-arch lisp kernel
    Foo.x8632 <- architecture
    Foo.ppc32 <-  specific
    Foo.x8664 <-    heap
    Foo.ppc64 <-     images

This doesn't preclude eventually concatenating everything into one
(perhaps very large) file, if and when there's a bit of technology
that can be used to find the architecture-specific parts of that file.
It's frankly not clear to me why anyone would care whether there was a
single file or several in the .app case, since one pretty much has to
distribute the whole bundle anyway.  Whatever control "Get Info" and
related tools offer over displaying available architectures and changing
the "preferred" architecture would still work (and would affect the
multi-arch lisp kernel.)