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
|
[[!meta title="Static libopkg"]]
[[←_Back_to_Opkg in ProteanOS|dev/pkg/opkg]]
Background
==========
ProteanOS currently dynamically links the `opkg` executable against a
`libopkg.so.1` shared object and provides the latter in a separate `libopkg.1`
binary package for use by any other applications that might also use libopkg.
In ProteanOS, only the `opkg` package depends on `libopkg.1`. Additionally,
there don't seem to be any other actively maintained applications, at least none
released publicly, that use libopkg.
With only one dependent executable, a library is more space efficient when
statically linked into that executable than when built as a shared object and
dynamically linked into the executable. The reason is that the library's
symbols can be stripped if statically linked into the executable. The symbols
in a shared object, on the other hand, are needed at run time to resolve uses of
those symbols in the executable to their addresses in the shared object.
Therefore, on a ProteanOS system that uses opkg but doesn't need libopkg for any
other applications, some space can be saved by statically linking libopkg into
the `opkg` executable. There are a couple of ways this can be done.
Options
=======
Option 1
--------
One option is to simply statically link libopkg into the `opkg` executable in
the `opkg` binary package and drop the `libopkg.1` and `libopkg.1-dev` binary
packages. This is the simplest option and saves the most space overall in the
package archive, however it doesn't allow any future libopkg-using applications
to be added to ProteanOS.
Option 2
--------
Another option is to leave the `libopkg.1`, `libopkg.1-dev`, and `opkg` binary
packages as they are and introduce a new `opkg-static` package with an `opkg`
executable statically linked with `libopkg.so.1`. The `opkg` binary package
would continue to depend on `libopkg.1`, while `opkg-static` would not. This
allows platforms *without* other libopkg-using applications to use opkg without
libopkg's symbols and allows platforms *with* other libopkg-using applications
to share libopkg between multiple executables. This however comes at the
expense of slightly increased package archive size (and, more importantly,
slight increases in the sizes of package feed index files cached on ProteanOS
systems).
An alternative to the naming of the `opkg` and `opkg-static` binary package
names is to use `opkg-dynamic` and `opkg`, respectively.
Option 3
--------
A compromise between options 1 and 2 is to leave the `libopkg.1` and
`libopkg.1-dev` binary packages as they are and statically link the `opkg`
executable in the `opkg` package with libopkg, without building an additional
package with an `opkg` executable that dynamically links against libopkg. This
means duplicated code and some increase in file system usage on any platforms
that may someday include some other libopkg-using application in the future.
But it also minimizes file system usage on platforms where opkg is the only user
of libopkg, like option 1, and balances package archive size between options 1
and 2 (and has the same package feed index file sizes as option 1).
Conclusion
==========
We'll probably go with option 1 at first. If we add any other libopkg-using
applications in the future, we can switch to option 2 with the `opkg-dynamic`
and `opkg` binary package naming scheme, for backwards compatibility.
|
