Re: universal binaries

[Graham J Lee]

On 16 Sep 2007, at 15:35, Frederico Muñoz wrote:

> Hello,
>
>
> On 9/16/07, Graham J Lee <leeg@thaesofereode.info> wrote:
> > On 16 Sep 2007, at 03:35, Frederico Muñoz wrote:
>
>
> > > Next comes different information about the addressing of the  
> > > archive.
> > > We see the offset, which tells us where the program starts in this
> > > file, and how large that block is(...)"
> > >
> > >
> > > > > With Mach-o?
> > > >
> > > > I don't think this is limited to some sort of ABI other than by
> > > > patent issues. In principle, you should even be able to stitch
> > > > together mach-o and ELF binaries. You'd have to modify the current
> > > > Mac OS X kernel to get this working.
> > >
> > > Indeed, I see no reason for not being possible to have ELF and  
> > > Mach-O
> > > mixed in the same MAB (which is not saying much since I know very
> > > little on how these things are processed at this level).
> >
> > The main problem with Mach-O style fat files is that they aren't
> > expressive enough.  For instance, it's reasonable to assume that if
> > you've got a PPC Mach-O segment, it's designed for Darwin (it might
> > instead be a Rhapsody binary which Darwin can't load, but the chances
> > are small; similarly few OPENSTEP users are going to try deploying
> > OS4.x binaries to Mac OS X for Intel).
>
> Yes, the format seems to assume a direct link between CPU architecture
> and underlying OS. I *think* that the NeXTStep fat binaries used the
> same analogy, with Solaris linked to Sparc and HP-UX to PA-RISC.

Actually, it always assumes Mach OS (and a Mach OS capable of doing  
something with the underlying binary, at that).  NS SPARC binaries  
were for NeXTSTEP/Mach on SPARC (similarly with PA-RISC); OPENSTEP  
for Solaris was a set of libraries and apps for Solaris which  
compiled ELF binaries, Mach-O SPARC binaries couldn't be run by  
Solaris.  Similarly i386 Mach-O binaries couldn't be run by Windows,  
and OPENSTEP Enterprise generated Windows binaries.

> > But that's not good enough
> > for GNUstep; is an 'i386/I386_SUBTYPE_ANY' ELF binary destined for
> > Linux, HURD, Solaris, FreeBSD...?  While it's true that a good ELF
> > loader would nicely fail if presented with a wrong object, it'd be
> > better to have a wrapper format specifying the OS in some way to
> > provide a truly cross-target fat file format.
>
> Yes, with multiple OS's possible for any given architecture the CPU
> approach is simplistic. One possible way would be to use the CPU
> subtype flag to indicate a CPU+OS pair (I'm not even considering
> different libc). This could work, although it would be a kludge.

I'm not sure it could work, because you can't trust a different Mach- 
O distributor not to re-use the I386_SUBTYPE_SOLARIS_10_ELF flag for  
something else, like I386_SUBTYPE_CORE_3.

> Another would be to use just one such flag to indicate a GNUstep
> binary, which in turn would have a more rich format which could
> contain multiple binaries. Possible, but perhaps not elegant.

I don't think it's GNUstep's problem at all, rather it's a problem  
for the OS vendors ;-).  And a small enough problem that most of them  
haven't worried about finding a solution, let alone a common  
solution.  Look at Sun, who support four binary formats (SunOS4/ 
SPARC, Solaris2/SPARCv7, Solaris2/SPARCv9, Solaris2/x86_64) and don't  
feel the need for a fat binary file format.

Cheers,
Graham.