Ship GIT

[Shinmera]

Git is an essential tool for modern development and shipping it (+magit) sounds like a jolly idea to me. Depending on how much needs to be included to sport that though I might reconsider this.

[Shinmera]

As per f3d8981 onwards this should be in now.

[Shinmera]

Reopening this because GIT is being absolutely horrendous to ship. When built on certain systems some of its components seem to segfault for no (to me) discernible reason. The failure point is usually git-remote-http, in some libcurl call.

Configurations known to work:

• OS X 10.11, Brew
• Linux Mint 17.1

Configurations known to break:

• Arch Linux
• Windows, MinGWx86_64

[Shinmera]

The previous breakage is explained by the following fun story:
The thing I was testing was git-remote-http which apparently segfaulted under strange circumstances. The one difference between the setups that I did not notice was that on Arch the root repository that I ran the git-remote-http in had an SSH origin. Apparently git-remote-http does not test whether the origin it gets is even valid for itself, and instead just segfaults if it encounters an URL it does not handle. Since my test machines were set up with an HTTPS clone they worked fine.

Now, on to Windows. Windows has a few more issues, namely every git command crashing if you compile it with NO_GETTEXT, saying something akin to "your vsnprintf is broken". The only reference to this that I could find is a prior bug in gettext itself that stemmed from a _vsnprintf and vsnprintf definition difference in MinGW that was not handled. I assume this special casing has not been backported to Git because there's probably nobody who ever built Git without gettext on Windows. We "solve" this by begrudgingly including gettext anyway.

Now, the next issue is getting Curl/Git to find the ca-certificates.crt file. No matter whether I place the file as curl-ca-bundle.crt right next to all the git binaries or set the CURL_CA_BUNDLE envvar to its location, nothing seems to work properly. straceing the execution does not even show an attempt to find that file. I assume Git has the path hardcoded into itself and passes it on to Curl. We can tell Git about the location of the file through the http.sslcainfo configuration value. However, since we can't use relative paths in that and absolute paths are a no-go due to relocation, we have to do more work. The solution is to introduce a proper unix shell environment (bash.bat) from which the git commands can bootstrap themselves. This environment sets the portacle root as the filesystem root, thus allowing us to specify an "absolute path" in the git configuration, while the path is actually relative to the entire system.

More fun because that's not directly possible. Git bakes the content of the prefix envvar into its executable to calculate the system-wide config from, so we have to change our build to use a prefix that is relative to the portacle root.

[Shinmera]

My brain is collapsing in on itself

[Shinmera]

We are almost done. The last remaining hurdle was fortunately no longer a matter of recompiling git, but rather an issue in the scripting and wrapping of the binaries that got resolved through some emacs config changes.

See 06e1248

[Shinmera]

Ayyyy, I really thought I was done there, eh. Well, time to think again, lol.

The ld-linux.so trick doesn't work any longer when another program is execed. The new program will use the system ld-linux, so we need to actually also wrap execve to inject ld-linux.so again for all future calls. Great!

[Shinmera]

I got a wrapper that seems to kinda work (ld-wrap.c), except git doesn't like it for to me unknown reasons. It just fails on things like git fetch and push.

[Shinmera]

Thanks to LD_PRELOAD and the exec* wrappers, this is now dealt with.