git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
	Elmar Pruesse <p@ucdenver.edu>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Reducing git size by building libgit.so
Date: Wed, 12 Jun 2019 16:29:32 +0700	[thread overview]
Message-ID: <CACsJy8BxdvOrc28_JhAARzJdOqyqWZaFX8DoPjEr4BCe-sRqsg@mail.gmail.com> (raw)
In-Reply-To: <20190611234815.GB8616@genre.crustytoothpaste.net>

On Wed, Jun 12, 2019 at 2:11 PM brian m. carlson
<sandals@crustytoothpaste.net> wrote:
>
> On 2019-06-11 at 19:52:18, Elmar Pruesse wrote:
> > Hi!
> >
> > The total compiled size of libexec/git-core is currently somewhere
> > around 30 MB. This is largely due to a number of binaries linking
> > statically against libgit.a. For some folks, every byte counts. I
> > meddled with the Makefile briefly to make it build and use a libgit.so
> > instead, which dropped package size down to 5MB.
> >
> > Are there, beyond the ~20 ms in extra startup time and the slightly
> > bigger hassle with DSO locations, reasons for the choice to link statically?
>
> I think the reason is that libgit is not API stable and we definitely
> don't want people linking against it.

Having .so files does not mean it's stable API though. If we don't
ever install header files, there's no way for outside people to use it
(people who dlopen() it anyway deserve whatever they get). I do agree
with some hassles from .so files though.

If installation size is a problem I think we can still shrink it a bit
down. Some non-builtin commands (fast-import, sh-i18n--subst...) could
be merged back in "git" binary. Some other for remote side (or
background daemons) could also be bundled together unless there's
security concerns.

We could also have a look at function distribution in libgit.a. I'm
surprised git-credential-store is 5.6 MB on my machine. We probably
pull more stuff than needed somewhere due to dependency between .o
files.

> Before libgit2 existed, projects
> like cgit built their own libgit and it required pinning to a specific
> version of Git.
>
> Also, some people install Git into their home directories, and a shared
> library means that they'll have to use LD_LIBRARY_PATH (or equivalent)
> to run Git.
>
> Finally, we have support for a runtime relocatable Git which can be run
> out of any path and still automatically find its dependent binaries.
> That won't work with a shared library.
>
> So if we did allow for building a shared library, it would have to be an
> option that defaulted to off, I think.
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204



-- 
Duy

  reply	other threads:[~2019-06-12  9:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11 19:52 Reducing git size by building libgit.so Elmar Pruesse
2019-06-11 23:48 ` brian m. carlson
2019-06-12  9:29   ` Duy Nguyen [this message]
2019-06-12 13:57   ` Paul Smith
2019-06-12 23:31     ` brian m. carlson
2019-06-13 19:19       ` Johannes Sixt
2019-06-13  7:51     ` Johannes Schindelin
2019-06-13 17:28       ` Paul Smith
2019-06-13 18:23         ` Junio C Hamano
2019-06-12  9:41 ` Ævar Arnfjörð Bjarmason
2019-06-12  9:46   ` Duy Nguyen
2019-06-12 10:25   ` SZEDER Gábor

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACsJy8BxdvOrc28_JhAARzJdOqyqWZaFX8DoPjEr4BCe-sRqsg@mail.gmail.com \
    --to=pclouds@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=p@ucdenver.edu \
    --cc=sandals@crustytoothpaste.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).