From: Omar Sandoval <osandov@osandov.com>
To: Dimitri John Ledkov <xnox@ubuntu.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Clarification needed about libbtrfs & libbtrfsutil
Date: Mon, 14 May 2018 13:22:13 -0700 [thread overview]
Message-ID: <20180514202213.GD13417@vader> (raw)
In-Reply-To: <CANBHLUjcAjvcA3BCn=i4VmDvKUcxSBk4_g3qp7Jw-k84sZXx5g@mail.gmail.com>
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.
next prev parent reply other threads:[~2018-05-14 20:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-14 8:40 Clarification needed about libbtrfs & libbtrfsutil Dimitri John Ledkov
2018-05-14 20:22 ` Omar Sandoval [this message]
2018-05-15 8:14 ` Dimitri John Ledkov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180514202213.GD13417@vader \
--to=osandov@osandov.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=xnox@ubuntu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.