Clarification needed about libbtrfs & libbtrfsutil

Clarification needed about libbtrfs & libbtrfsutil

[Dimitri John Ledkov]

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?

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.

-- 
Regards,

Dimitri.

Re: Clarification needed about libbtrfs & libbtrfsutil

[Omar Sandoval]

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.

Re: Clarification needed about libbtrfs & libbtrfsutil

[Dimitri John Ledkov]

On 14 May 2018 at 21:22, Omar Sandoval <osandov@osandov.com> 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.