1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
|
[[!meta title="Multiarch"]]
Multiarch refers to the ability to install and use packages built for non-native
architectures. It is currently being [documented and implemented][wdo-ma] in
Debian and Ubuntu. Multiarch is useful for this distribution because it makes
cross compiling easy (see "Package Cross Building Tool" and "Multiarch Cross
Toolchain Packages").
Simply speaking, there are six [aspects of a multiarch implementation][ma-des]:
* **Filesystem Hierarchy**
To accomodate simultaneous installation of shared libraries built for
different architectures, library paths are suffixed with a directory name
that identifies a particular architecture. For this distribution, that
directory name will be the name of the binary architecture; for example,
library paths for the `cortexa8-linux-eglibc` architecture will be
`/lib/cortexa8-linux-eglibc` and `/usr/lib/cortexa8-linux-eglibc`.
The toolchain (especially the dynamic linker) needs to be configured to use
these library paths.
* **A `Multi-Arch` Control Field**
A `Multi-Arch` control field specifies how a package can satisfy
dependencies of other packages. A value of `same` means that a package can
only satisfy dependencies of packages built for the architecture for which
it was built. This is useful for shared libraries, which can only be
dynamically linked against binary objects built for the same architecture.
A value of `foreign` means that a package can satisfy dependencies of
packages built for any architecture. This is useful for utility programs,
which can be used by software built for any architecture.
The package manager (opkg in our case) and package building tools
(specifically oh-checkbuilddeps of opkhelper) must be able to understand
and use this field in resolving package dependencies.
* **Architecture Specification in Package Relationships**
Control fields like `Depends` are extended to support an architecture
specification of either `any` or `same`, allowing a package to specify
whether or not it needs a package of the same architecture. The dependent
package has a `Multi-Arch` field with value `allowed`.
The package manager and package building tools must be able to understand
and use this architecture syntax in relationship fields.
* **Handling of Packages with `Architecture: all`**
Dependence on packages installable and usable on any architecture
(especially considering opkg's ability to install packages of multiple
architectures) must be researched.
* **Non-Library Files in Library Packages**
Library packages provide files outside of system library paths, such as
configuration and package documentation files. A solution must be designed
to allow a package built for one architecture to be co-installable with the
same package built for a different architecture (or to determine if they are
co-installable at all).
* **Ability to Install Packages Built for Non-Native Architectures**
The package manager must be able to install packages built for multiple
architectures (the whole point of multiarch). Fortunately for us, opkg
already handles this. The `arch` option in `opkg.conf` [allows the user to
specify architectures][opkg-conf-arch] for which packages can be installed.
In summary, there is much design work to be done, opkg and opkhelper must be
modified to support multiarch, and certain packages will need to be built to
handle multiarch library paths. Of course Debian is a great reference
implementation, but there still remains much original work to be done.
[wdo-ma]: http://wiki.debian.org/Multiarch
[ma-des]: https://wiki.ubuntu.com/MultiarchSpec#Design
[opkg-conf-arch]: http://wiki.openwrt.org/doc/techref/opkg#adjust.architectures
|
