[EMAIL PROTECTED] writes:
> 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.
A proposed solution to this is pretty simple:
dpkg/apt can check all archs compatible with the cpu (and enabled in
the config). That means on i686 it can check i486, i585 and i686.
When installing dpkg/apt look at the ABI of each package instead of
the architecture and i[456]86 are all ia32. Those package naturaly
conflict and only one of them can be installed in parallel.
Whether you use i486-linux-gnu or i686-linux-gnu for i686 optimized
packages remains open but it is a simple change for the ld to include
that dir. If i686-linux-gnu is consistently used for i686 optimized
packages then one could even allow installing i486 and i686 flavours
of a package and have any of them suffice for a depends.
> 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.
That support is arch specific and varies widely between archs. It also
goes into "minor" differences within one arch, e.g. i686 is available
with and without cmov instruction.
> 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
Given that ld already covers the subelties of different i*86
architectures many people feel it is best to leave it there and just
put all i*86 in i486. After all, they are all one ABI and that is what
we actualy sort for.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
