On 14 May 2018 at 21:22, Omar Sandoval <osandov@xxxxxxxxxxx> wrote: > 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. > Ack. Will ship them as such. >> 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. OK. I guess I can prepare a patch to dynamically link libbtrfs/libbtrfsutil and see how that will go through review. -- Regards, Dimitri. -- 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
