Arnd Bergmann wrote: > Exactly. Note that nowadays, all the important architectures > support running i386 binaries with qemu, but amd64 is the only > one that can run them with native speed. It may become 'interesting' > if qemu or ia64 start supporting amd64 binaries. Imagine a > 64 bit power mac with /lib, /lib64, /libosx, /libx86 and /libamd64 ;-) [Drift: On the one hand there is the /lib<qual> specification. On the other there is /emul/ specification. They seem to be at odds with each other. Perhaps someone could enlighten me as to the comparison and conflicts?] > Seriously, for non-native emulated binaries, having a full > file system hierarchy below /emul/<arch>-<os>/, e.g. > /emul/i386-linux/, probably makes more sense. > > But doing so with Debian is an exercise left for the reader. Recently I posted a note in debian-ia64 which is related to this problem. It describes using an alternative chroot methodology to manage emulation binaries other than the currently provided ia32-libs package. Using a chroot environment allows you to manage the emulation layer using a native, but separate, dpkg instantiation. For me personally it works pretty well and is the best I can do right now since dpkg does not understand about multiple architectures on the same machine. I am sure there is applicability to x86-64. http://lists.debian.org/debian-ia64/2003/debian-ia64-200303/msg00012.html But this is not completely without problems. In the discussion of that thread talking about OpenOffice I describe why the difference between binaries and scripts are significant. http://lists.debian.org/debian-ia64/2003/debian-ia64-200303/msg00017.html Basically a script probably won't be in the emulation layer if the interpreter is provided outside of it. Which means you can get into a case where script and the binaries it is running don't have the same view of the filesystem. They will be out of sync. The OpenOffice scripts were looking for things which only existed in the emulation layer and not outside of it and so failed to work out of the box like that. I used symlinks to work around this for the specific case of OpenOffice. But it is not as clean as I would like it to be. > The feature is also interesting for i386, because it can make it easy > to support i686 or i486 optimized packages. The relationship > between amd64 packages and their i386 counterparts is > not all that different from the i686 vs. i386 relationship. This topic comes up often on debian-devel. Always a hotbed of discussion. Since there has never been a good resolution of the i386/i686 problem I fear that there will not be a good resolution to the i386/x86-64 problem in the near future either. Bob
Attachment:
pgpTPzlmGjgGK.pgp
Description: PGP signature