Re: multiarch -- crucial naming problem with noncanonical system names
We've discovered a critical problem with the multiarch proposal. I
don't know where to send this, but it needs to be sent somewhere!
(I said):
>>Why not just use the canonical system name?
Goswin von Brederlow wrote:
>
>
> No reason. But how do we get that name?
>
> The existing multiarch proposals have all been using gcc -dumpmachine,
> either explicitly or just the output of it. For sarge that ment
> i486-linux, x86_64-linux, ... In sid this became i486-linux-gnu,...
You might be surprised at how GCC gets that name. It gets that name
based on what's passed to 'configure' when GCC is configured. So if you
type '../gcc-src/configure i486-linux', it's 'i486-linux'; if you type
'../gcc-src/configure i486-pc-linux-gnu', it's 'i486-pc-linux-gnu'. Et
cetera.
This means that -- unless you specify carefully what you're doing -- it
will be different from distribution to distribution based on the GCC
package maintainer's whim or habit.
The only reason it changed in sid was that a different string was passed
in debian/rules in the GCC package. How's that for a bad reason?
We should almost certainly specify that one specific name *must* be
used, and I believe it should be the full canonical system name: the
result of applying ./config.sub to any of the other names.
Cc:ing to debian-gcc@lists.debian.org, because this is quite definitely
relevant.
> People have already mentioned that for mips64 there are two abis: n32
> and n64 that both fall under mips64-linux-gnu. Something has to be
> done there.
I believe N32 is the default, last time I checked the source code; there
doesn't seem to be a separate canonical triple to use to make N64 the
default, which is kind of obnoxious, and there probably should be.
(Incidentally, the canonical form is mips64-unknown-linux-gnu ; any of
mips64-linux, mips64-linux-gnu, and mips64-unknown-linux-gnu could be
used to create essentially identical compilers with different results
from 'gcc -dumpmachine'. Eeewwww....)
(I wrote):
>>Please note that gcc's subdirectory is currently named according to the
>>arguments passed to gcc's configure script. I always wanted it to be
>>the canonical system name, but a bunch of people do strange things like
>>configuring three versions of gcc, one with 'i486-linux', one with
>>'i486-linux-gnu', and one with 'i486-pc-linux-gnu' with the deliberate
>>intent of keeping multiple versions with the same version number (but
>>presumably different patches or configuration options) installed at once
>>for testing purposes. This is all good and well, but it's not the model
>>to follow when making a standard, and I hope it doesn't get followed.
>
>
(Goswin von Brederlow wrote):
> If you want to change the gcc name and if the gcc name is reused for
> multiarch dirs then you better hurry up and get that changed
> quickly. Once packages do start using the multiarch dirs in sid
> changing it becomes ugly. Libc, bnutils and gcc have to support the
> old and new names for a transition period, which should be at least 2
> releases. So we realy don't want to change that once it is in use.
You gotta watch out. Something *must* be done, because the GCC name is
currently *NOT* standardized in any way -- it's whatever the packager
decides to pass to 'configure'. (If you pass nothing, you'll get the
full canonical name for the local build system.) It's probably far
worse for Gentoo, where each individual may pass a different string!
It's absolutely insane and unacceptable to 'standardize' the multiarch
dir on the output of something which can be changed by typing a slightly
different (but supposedly equivalent) input when configuring GCC -- at
least unless you standardize what input should be used when configuring
GCC. I suspect the writers of the proposal did not realize that the
output of gcc -dumpmachine is *NOT* standardized in any way, shape, or
form. You are going to get different directory names on Red Hat than on
Debian (for essentially the same architecture) if you don't standardize
this.
If you folks liked, we could push upstream to change the GCC name to use
the *canonical* name rather than the noncanonical name. I would like that.
This would probably be an easier sell with the motivation of multiarch
behind it than it was last time I tried to do it, when it got slapped
down for the reasons noted above.
This is a fairly straightforward change; you could actually put it into
the Debian package if you liked. To do it, essentially you just replace
all uses of "target_noncanonical" with "target" (and "host_noncanonical"
with "host"). (You actually only need to replace some of them, but
which ones is a bit tricky to figure out.)
Note that you don't really lose any compatibility by doing this
unilaterally, since if someone built the current versions while
explicitly passing the full canonical system name (which is perfectly
legal), they'd get the same results. This is simply a matter of
standardization versus non-standardization.
../gcc-src/configure i486-pc-linux-gnu
(Goswin von Brederlow wrote):
>>>PS: A change in the multiarch dir has to be pushed into the FHS
>>>multiarch proposal as well.
>>
(I wrote, and it's true of this too):
>>Please forward this (or any subset of it you like) to anywhere where it
>>is appropriate. I'm not sure where multiarch is being discussed: the
>>document http://www.linuxbase.org/futures/ideas/multiarch/ says to send
>>additions or corrections to Matt Taggart, but lists no email address.
>
>
> MfG
> Goswin
>
Reply to: