Re: multiarch status update
>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
Reply to: