[EMAIL PROTECTED] wrote:
> >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.
To expand a bit on this, I don't think config.guess is sufficient to
handle those cases. E.g. for a MIPS system with 64bit kernel,
config.guess will return
mips64el-unknown-linux-gnu
even when there's only a (little endian) O32 userland installed, but
for a 32bit kernel it will be
mipsel-unknown-linux-gnu
unless the call is prefixed with linux32, which changes the uname,
and thus the config.guess output.
The endianness is guessed from the defaults of the system compiler
(the first cc in $PATH), which is
a) not necessarily available, and
b) supposed to be exchangable in a full multiarch environment.
What's worse, "mips64" is a rather entrenched term with inconsistent
meanings which cover both the N32 and N64 ABI. A "fix" to config.guess
would AFAICS require to specify a multiarch mode, which changes the
output to, say, mipsn32el-unknown-linux-gnu for N32 and to
mipsn64-unknown-linux-gnu for N64 (that still doesn't answer the
question which ABI would be the "native" one). But in that case the
config.guess can't be the canonical source of information any more.
This is not only MIPS-specific, a similiar problem arises e.g. for a
ILP32 ABI for x86_64.
I think we need a canonical ABI-OS (or ABI-KERNEL-OS ?) table which
provides mappings for multiarch-sensitive programs.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
