[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: universal binaries
From: |
Frederico Muñoz |
Subject: |
Re: universal binaries |
Date: |
Mon, 17 Sep 2007 02:54:31 +0100 |
Hi,
On 9/16/07, Markus Hitter <mah@jump-ing.de> wrote:
>
> Am 16.09.2007 um 16:35 schrieb Frederico Muñoz:
>
> > One possible way would be to use the CPU
> > subtype flag to indicate a CPU+OS pair
>
> Once I step slightly away from the name "cputype" and start to think
> about "architecturetype" or "platformtype" I can't see a kludge here.
> Subtype (probably, I'd have to check) works slightly differently as a
> G4 CPU can run G3 binaries but not vice-versa.
>
That's what I was suggesting, making the cputype a placeholder for a
more meaningful relation of hardware and OS. As Graham rightly noted
though any use of this would work as long as the values chosen weren't
latter reused by Apple to mean something else: while adding stuff to
the MAB's wouldn't bother the "official" tools for now, latter they
could be rendered useless by conflicting definitions.
> > (I'm not even considering different libc)
>
> Libraries use the same mechanism, so your libc has to contain a
> cputype/architecturetype/platformtype matching your actual hardware.
>
If I understand this correctly this is how GNUstep's non-flatened app
structure work, and has full support of the runtime (especially since
since it uses discrete binaries it dispenses any kind of special exec
cooperation). This approach is elegant IMO, especially since nothing
important is actually gained from having the binary in the same
archive as opposed as different binaries that are selected at
run-time. It wouldn't work in OSX though (I mean, not using GNUstep).
> > In the end I'm not sure that MAB's are worth the trouble given all
> > this if
> > one takes out the "coolness " factor (i.e. the exact some app running
> > on OSX and GNUstep), which is perhaps somethings that appeals on a
> > more emotional level than purely practical.
>
> You need kernel support ... if you have this kernel support, FAT
> binaries are not limited to Cocoa/GNUstep but would work for all
> types of executables.
>
Well, as I said kernel support in GNU/Linux doesn't mean having to
mess with the kernel source, since there are modules like binfmt_misc
that simplify the process greatly, but I get your point. For me the
only allure this kind of MAB's have is e.g. having the same Emacs.app
running on both OSX and, say, ix86 GNUstep. But again, this is
simplistic and probably not worth the effort in a purely practical
perspective. From a show case perspective,it would perhaps impress
someone though.
Cheers,
Frederico Muñoz