>I have created a new page in the wiki to track info and status > > http://wiki.debian.org/multiarch
I looked at the "upstream standards proposal": http://lackof.org/taggart/hacking/multiarch/ It's good. I am particularly pleased by the specification: "The terms arch and os represent the Architecture and Operating System as defined and provided by config.guess." It is crucial that this naming be entirely standardized. This *should* be sufficient. Is it sufficient? Cases where it would not be sufficient would be the following: (1) Cases where config.guess reports the same name for functionally different systems, such as the two MIPS ABIs. This should be considered a bug in config.guess, plain and simple. (2) Cases where config.guess gives noncanonical results. This should not happen, and if it does it's a bug in config.guess. (3) Cases where the *manufacturer name* is the sole discriminator between two functionally different systems. While this *is* the case for some legacy UNIX systems, I believe it is not the case for any system which might consider using the FHS or multiarch, or indeed for any common system, so this is probably not important. However, it could be avoided by simply using the full canonical system name. However, there are arguments against that, notably the use of the 'manufacturer' slot in unreliable and inconsistent ways by Linux distribution vendors, despite no real platform difference. (4) There is an ambiguity in the specification. config.sub notes: # The goal of this file is to map all the various variations of a given # machine specification into a single specification in the form: # CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM # or in some cases, the newer four-part form: # CPU_TYPE-MANUFACTURER-KERNEL-OPERATING_SYSTEM I believe that when it is the output of config.guess, the KERNEL-OPERATING_SYSTEM should be considered the $os portion in a multiarch implementation. This will be necessary to discriminate between different systems. This would be the natural result of the naive implementation (which doesn't consider the existence of four-part canonical system names) anyway. (5) config.guess has been known to vary its output from system to system when perhaps it shouldn't. :-) It will be necessary to standardize the canonical system names for multiarch in this case: it is crucial that we not have (for instance) i486-linux and i486-linux-gnu directories floating around separately. Accordingly, I suggest that the upstream proposals should *specify* the expected $arch-$os results from config.guess for the common, existing platforms. ----- There is yet another issue with the $arch portion of the canonical system name: chips which are upgrades of other chips. For instance, Fedora will give you 'i686', while Debian will give you 'i486'. This will (and should) result in two different directories -- different multiarch variants. However, programs compiled for i486 will run on i686. This raises fairly complex program interpreter issues for the simplest case (intercompatibility between Debian and RedHat on x86). Software must expect to be able to install to the i486-linux-gnu directories and function immediately, even on a "natively" i686-linux-gnu system. Likewise software should be able to install to the i686-linux-gnu directories and function immediately if the chip is actually an i686, even on an i486-linux-gnu system. Now, this is in fact trivial with the current non-multiarch situation. We must be careful not to break it with multiarch! Perhaps an "x86 annexe" to the specifications would help? I *believe* that this can be handled as follows: (1) Specify a list of arch-os pairs which are ABI-compatible (i486-linux-gnu, i586-linux-gnu, i686-linux-gnu perhaps) (2) Rework the program interpreter to search through all three arch-os pairs, starting with the "highest" one which the actual chip supports. However, this all seems to duplicate the existing functionality with /usr/lib/tls/{i486, i586, i686}. But perhaps it should be considered to be replacing that functionality? That seems like a wise way to go, actually. If not, it may be simpler to just specify outright that all x86 machines should use i486-linux-gnu, NOT i686-linux-gnu, regardless of what config.guess thinks, and that libraries compiled for the higher chips should use the subdirectories. Please consider the x86 intercompatibility case before making any final proposals. It's very important. :-) --Nathanael Nerode -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
