Currently, taking a dep on libzfs means your crate gets linked against
libzfs.so.2 libzpool.so.2 and libnvpair.so.2. Take device-aggregator for
instance, which only takes a dep on libzfs to get shared types:
$ ldd /usr/bin/device-aggregator
linux-vdso.so.1 => (0x00007ffdba5b8000)
libzfs.so.2 => not found
libzpool.so.2 => not found
libnvpair.so.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007f49332af000)
librt.so.1 => /lib64/librt.so.1 (0x00007f49330a7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4932e8b000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f4932c75000)
libc.so.6 => /lib64/libc.so.6 (0x00007f49328a8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4933905000)
libm.so.6 => /lib64/libm.so.6 (0x00007f49325a6000)
We don't need libzfs to be linked in crates that only need type access.
Instead, extract types to their own standalone crate that doesn't have a
dep on libzfs-sys. This way we can get type access without linking to
unneeded shared objects.
Currently, taking a dep on libzfs means your crate gets linked against libzfs.so.2 libzpool.so.2 and libnvpair.so.2. Take device-aggregator for instance, which only takes a dep on libzfs to get shared types:
We don't need libzfs to be linked in crates that only need type access. Instead, extract types to their own standalone crate that doesn't have a dep on libzfs-sys. This way we can get type access without linking to unneeded shared objects.
Signed-off-by: Joe Grund jgrund@whamcloud.io