Perry Hutchison wrote: > If we need /proc, wouldn't we _already_ be unhappy inside a chroot > that didn't mount /proc, even _with_ fallback to static paths? > Last I knew, the whole point of chroots/containers/jails/etc. was to > prevent access, from a process running inside the container, to any > part of the FS that's outside of the container.
Yep. The code also allows for use of "argv[0]", but that has its own set of problems. These were previously covered in the discussions leading up to the patch landing, but to summarize, "argv[0]" can be completely manipulated by the calling process, whimsically or in response to constraints such as links, and is wholly unreliable for self-location. Other kernels have their own behaviors with respect to path self-location, and none seem to be straightforward. This link seems to have a good rundown of the details and differences: https://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe All things considered, I think executable path self-location is markedly more fragile than using static paths, both with increased dependencies and added inconsistent behavior and limitations, and should not be the default on any platform. Both Johannes' original RUNTIME_PREFIX implementation for Windows and the Linux/etc. expansions that I did were written to serve constrained special case deployments. In that capacity, they can be really useful, as the fragility is managed by their respective environments. My particular use case served the purpose of building Git once and deploying it via archive on other systems. This capability requires the additional work of building portable versions of Git's dependencies and their associated resources, and statically linking everything together. This is a lot more portability than the conventional user requires, and also necessitates a significantly more complex build process. However, making Git itself portable via RUNTIME_PREFIX without similar work on its dependencies limits the usefulness of that portability, since it's still bound to the system's libraries and their resources. Cheers, -Dan
