Bugzilla – Bug 386
unbound binaries does not link against libunbound
Last modified: 2011-05-10 12:57:56 CEST
The unbound build does not link against libunbound.so.2, making the binaries larger than necessary. Observed on OpenWrt, Debian, Ubuntu and local build on Ubuntu. Probably not very important on desktops and servers, but makes a big difference on embedded.
Ubuntu 11.04:
$ ldd /usr/sbin/unbound
linux-vdso.so.1 => (0x00007fff0ad67000)
libssl.so.0.9.8 => /lib/libssl.so.0.9.8 (0x00007f7a3c2a0000)
libldns.so.1 => /usr/lib/libldns.so.1 (0x00007f7a3c05a000)
libev.so.3 => /usr/lib/libev.so.3 (0x00007f7a3be4c000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7a3bc44000)
libcrypto.so.0.9.8 => /lib/libcrypto.so.0.9.8 (0x00007f7a3b8b5000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7a3b696000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7a3b302000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7a3b07d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7a3c526000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7a3ae78000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7a3ac60000)
Hi Cybjit,
This is true, the reason that this would not work is that libunbound does not export the internals, only the API is flagged as exportable.
What would be a fix is to have a new underlying library, with internals, that then is linked to unbound (-binaries) and to libunbound. In the Makefile.in you can see this is for the source files tagged COMMON_OBJ that are a good candidate for this.
I am apprehensive of this change, as it complicates the dynamic library loading, which is a sore topic for portability.
Best regards,
Wouter
Created attachment 167 [details]
give option to link binaries to library
Yes, I eventually realized this poking around Makefile.in. In my testing I got the install down to about 1/3 by removing the symbol restriction and linking the binaries.
I am unsure if adding another library would be helpful sizewise.
I am not sure what else to do beside a library. Is a multi-call binary more portable than a library?
Attaching my draft for exporting all symbols and linking.
This patch looks nice, I have put it into the svn trunk (with small changes: explained the help string that it decreases install size, but pollutes the libunbound exported namespace).
Thanks,
Wouter