Static libopkg

← Back to Opkg in ProteanOS

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.