Messages in this thread | | | From | Werner Almesberger <> | Subject | Re: FAT binaries and Linux | Date | Fri, 19 Sep 1997 09:38:26 +0200 (MET DST) |
| |
Richard Henderson wrote: > Hah. Sharing data is _very_ hard.
No, it's very easy if you don't try to be clever, see below ;-)
> You'd have to modify the compiler to get it to output things that > you can expect to be able to share in separate sections (easy). > This is basicly limited to strings,
Not even that ! People may encode things like magic numbers in strings, which are then copied to and used as integer types. This is of course ugly, but you can't be sure it's not done somewhere ...
What I'm actually most concerned about are programs that "learn" what the architecture is like before compilation, e.g. Perl determines the byte order in Configure. There's no automatic way of getting FAT binaries for such programs right or even only to reliably refuse their creation.
> unless you want to muck with > partially shared sections (sparc shares with ppc, but i386 and > alpha don't share with anyone due to endian and word size).
Don't forget alignment, architecture-specific system headers like sys/types.h (__u32, etc.), architecture-specific numbering schemes (errno.h and such), etc. You can get it right, though: once you've created all the data areas, you can simply bit-compare them to see if there happen to be identical ones, then merge. Of course, given the constraints, merging doesn't seem very likely for anything more complex than /bin/true ...
> Fat binaries are, IMO, a waste of effort. Just bleeding deal with > N binaries for N architectures. It just isn't that hard.
They'd be nice in cases where you have programs you can trust not to gather architecture information before compliation (this includes manual Makefile editing). The key advantage of fat binaries is ease of handling and that you can be reasonably sure that foo.i386 is the same version as foo.sparc.
If you also have fat object files, build procedures are reduced from make clean, make_all, change_arch, make_clean, make_all (with assorted prayers that make clean really cleans up properly - anybody care to check if this is true in little gems like MH or BIND ? :-) to a simple make_all (Of course, there are some programs already supporting multi-architecture builds, but they're comparably rare.)
IMHO, fat binaries could be useful and it may be worth exploring that possibility. If they turn out to be bad, we can always license them to M$ ;-)
By the way, what are actually the experiences of the NextStep folks ?
- Werner
-- _________________________________________________________________________ / Werner Almesberger, DI-LRC,EPFL,CH werner.almesberger@lrc.di.epfl.ch / /_IN_R_133__Tel_+41_21_693_6621__Fax_+41_21_693_6610_____________________/
| |