[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: multiarch status update

neroden@twcny.rr.com 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.


Reply to: