Bug 386 - unbound binaries does not link against libunbound
unbound binaries does not link against libunbound
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
1.4.9
All Linux
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-07 14:33 CEST by cybjit
Modified: 2011-05-10 12:57 CEST (History)
1 user (show)

See Also:


Attachments
give option to link binaries to library (4.02 KB, patch)
2011-05-09 21:46 CEST, cybjit
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description cybjit 2011-05-07 14:33:28 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)
Comment 1 Wouter Wijngaards 2011-05-09 11:10:28 CEST
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
Comment 2 cybjit 2011-05-09 21:46:08 CEST
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.
Comment 3 Wouter Wijngaards 2011-05-10 12:57:56 CEST
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