Re: Reducing git size by building libgit.so

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 12, 2019 at 2:11 PM brian m. carlson
<sandals@xxxxxxxxxxxxxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux