On 2019-06-12 at 13:57:43, Paul Smith wrote: > 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. This is possible to do, but it's not especially portable. People use various C toolchains to compile our code, which may or may not have easy access to linker flags. The proper syntax also varies depending on whether you're using ELF, Mach-O, PE[0], or another object format. And Debian tries hard to avoid RPATH settings[1], so we'd need to be sure to have an option not to set it. None of these are intractable problems, but there's not simply an easy solution that we can magically set that will work everywhere. If we were using autoconf and friends exclusively, this would be easier, but we're not. So someone is welcome to attack these problems with a set of patches, but I expect it to be fairly involved to get all the corner cases right if we want to make it the default. [0] AFAIUI, Windows doesn't have RPATH-like functionality, and from what I've read, the same-directory behavior may be going away due to security concerns. I don't use Windows, so any solution there is fine as long as Dscho is happy. [1] https://wiki.debian.org/RpathIssue -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204