On Mon, May 14, 2018 at 09:40:19AM +0100, Dimitri John Ledkov wrote: > Are both of these meant to be public libraries, installed on the user > systems, and available in .so variant as well for 3rd party > development and public dynamic linking? > > Or are these private internal libraries, which are installed as public > runtime only, simply to share code between the utils, but otherwise > provide no abi stability and will forever remain libfoo.so.0? They're both meant to be public. In fact, libbtrfsutil is already 1.0.0. > Or should these even be a noinst_ libraries (~= Libtool Convenience > Libraries), and are simply intermediate by-products? > > I'm asking because despite compiling shared & static variants of these > libraries, and "shared linked" and "static linked" variants of the > utils, it appears that all utilities are statically linking against > libbtrfs/libbtrfsutils. Thus no binaries nor bindings, dynamically > link against neither libbtrfs nor libbtrfsutil. > > Tweaking the makefile to use libs_shared variable instead of libs or > libs_static, results in slightly smaller binaries, dynamically linked > against libbtrfs/libbtrfsutil. > > But it is hard to tell if this is a bug/mistake, or an intentional feature. I'm not sure why we statically link libbtrfs into the the tools, and I just copied that for libbtrfsutil. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
