All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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.