diff options
Diffstat (limited to 'dev')
| -rw-r--r-- | dev/pkg/opkg/static.mdwn | 70 |
1 files changed, 70 insertions, 0 deletions
diff --git a/dev/pkg/opkg/static.mdwn b/dev/pkg/opkg/static.mdwn new file mode 100644 index 0000000..cb623b2 --- /dev/null +++ b/dev/pkg/opkg/static.mdwn @@ -0,0 +1,70 @@ +[[!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 increased package archive size. + +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 `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. + +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. |