Multiple architecture problem and proposed solution

Introduction

We are seeing increasing cases of systems that have support for multiple binary targets. The FHS, LSB and other standards do not currently address several runtime issues related to this issue. Several partial solutions for various problems exist but are inconsistent and suboptimal.

This document seeks to record problem use cases, record current, solutions, propose a generic solution that covers as many of the use cases as possible, and detail the implications of such a solution.

Jump to: Problem | Proposal | Implementations | Benefits | FAQ

Problem

There are several classes of this problem:

  1. 32/64 Architectures

    Architectures with support for 32bit and 64bit versions of the same instruction set

    Examples:
    Current practices:
    Comments:
  2. Mixed instruction sets

    Architectures with support for running other instruction sets (either via hardware or software emulation)

    Examples:
    Current practices:
    Comments:
  3. Mixed OS environment

    Running binaries from one OS on another via a compatibility layer

    Examples:
    Current practices: Comments:
  4. Mixed endian

    Architectures that support running mixed endian binaries.

    Examples:
    Comments:
  5. Mixed ABIs and instruction set extensions

    Architectures with more than one ABI.

    Examples:
  6. Applications that support multiple archs/OSs

    Applications that support multiple archs/subarchs/OSs usually for cross development or performance reasons

    Examples:

Proposal

Required results
Desired results
Proposed General solution
Key: The term prefix is intended to be replaced with the FHS compliant install prefixes such as /, /usr, /usr/local, /opt/foo, etc. The terms arch and os represent the Architecture and Operating System as defined and provided by config.guess. The term target is meant to represent an arch-os binary target.

Implementation Options

Runtimes implementing this proposal can put the libraries/headers/program interpreters wherever they like as long as they can be accessed as described in the proposal. This allows for a range of possible implementations and the ability for a gradual transition. Here are some potential options.


Benefits


FAQ

  1. Isn't this impossible?
    No, Debian has a small-scale implementation already.
  2. Will all software need to switch to this proposal right away?
    No, they can continue to install to the existing paths indefinitely. The main reason for changing to the new model will be to enable that software to be used on a multi-arch system.
  3. Will I be able to install the same binary for two different targets on the same system?
    No, not without changing the name to avoid collision. This proposal assumes that bin directories don't need to be differentiated since users won't want more than one version of a binary installed. If there is demand for that it could be addressed in a similar manner, but we don't want to deal with it until there is sufficient demand.
  4. Linux's ldconfig will walk the whole prefix/lib/ tree finding libraries for various targets, won't it blow up?
    No, its smart enough to ignore stuff not for it's target.
  5. What about software that creates subdirectories under prefix/lib/ (or include)
    These will need to be evaluated on a case by case basis depending on if the content they are providing under that subdirectory is target specific.
  6. What about software with binary plug-ins like apache?
    You can't mix and match target plug-ins with one binary apache today. In the case where you could, that software would want to follow the proposal and structure their software accordingly to avoid filesystem collisions.
  7. Why not prefix/arch-os/lib/ (and include/)?
    It would pollute the prefix directory. Can you imagine adding one entry for each target to the root and /usr directories? Better that they go under the prefix/lib/ (and include/) directories which already contain many files.

Send additions/corrections to Matt Taggart <taggart@debian.org>
Last updated: Fri, 18 Jun 2004 06:29:41 -0400