Re: Reducing git size by building libgit.so

From: Paul Smith <paul@mad-scientist.net>
Date: Jun 12, 2019, 13:57 UTC
Message-ID: <9c488ce8c1e1e6d6d4c343b0b40c8a64c8147a7f.camel@mad-scientist.net>
In-Reply-To: <20190611234815.GB8616@genre.crustytoothpaste.net>

On Tue, 2019-06-11 at 23:48 +0000, brian m. carlson wrote:

> 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.

I don't have strong feeling about .so's although obviously less disk space used is always a good thing, everything else being equal.

However, the above concern isn't actually an issue. You can install the .so in a known location relative to the binaries, then link the binaries with an RPATH setting using $ORIGIN (or the equivalent on MacOS which does exist but I forget the name). On Windows, DLLs are installed in the same directory as the binary, typically.

Allowing relocatable binaries with .so dependencies without requiring LD_LIBRARY_PATH settings is a solved problem, to the best of my understanding.

One thing to think about is that runtime loading a .so can take some time if it has lots of public symbols. If someone really wanted to do this, the ideal thing would be to make all symbols hidden except those needed by the binary front-ends and have those be very small shells that just had a very limited number of entry points into the .so.

Maybe for git this doesn't matter but for some projects I've worked on the time to dlopen() a library was a blocking issue that the above procedure solved nicely.