{"thread":{"id":"48826","subject":"Git 2.18: RUNTIME_PREFIX... is it working?","startedAt":"2018-07-04T05:53:25Z","lastAt":"2018-07-20T14:29:06Z","messageCount":24,"participants":["Paul Smith","Johannes Schindelin","Daniel Jacques","Jeff King","Junio C Hamano","Perry Hutchison","Jonathan Nieder","brian m. carlson","Jeff Hostetler"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"351677","messageId":"97803ec8dae0a73bae301a37377b7b4a78f77e99.camel@mad-scientist.net","threadId":"48826","inReplyTo":null,"subject":"Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2018-07-04T05:12:13Z","receivedAt":"2018-07-04T05:53:25Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"I was excited to see the RUNTIME_PREFIX for POSIX systems patchset go\nby earlier this year.  Although I didn't see any mention of it being\nincluded in the 2.18.0 release notes, it does appear that it was merged\nin for this release.\n\nHas anyone else tried to get it working?  It doesn't appear to be\nworking properly for me so I'm not sure if I'm supposed to be doing\nsomething different... I didn't see any documentation on it.\n\nBasically what happens is that I run configure with\n--prefix=/my/install/path --with-gitconfig=etc/gitconfig\n--with-gitattributes=etc/gitattributes.\n\nThen I run make with RUNTIME_PREFIX=YesPlease.\n\nWhen I look in the makefile, I see that the make variable gitexecdir is\ninitially properly set to libexec/git-core which is what I expect.\n\nHowever, later in the makefile we include the config.mak.autogen file,\nwhich was generated from config.mk.in by configure.  In the .in file we\nhave this:\n\n gitexecdir = @libexecdir@/git-core\n\nAfter configure gets done with it, this becomes:\n\n gitexecdir = ${prefix}/libexec/git-core\n\nwhich is a fully-qualified path.  This means that exec-cmd.c is\ncompiled with -DGIT_EXEC_PATH=\"/my/install/path/libexec/git-core\" which\neffectively disables RUNTIME_PREFIX, as the exec-cmd.c:system_prefix()\nfunction always returns FALLBACK_RUNTIME_PREFIX since GIT_EXEC_PATH is\nnot a suffix of executable_dirname (once the install location has been\nmoved).\n\nI suppose we need to pass more configure options to reset paths; is\nthere information somewhere on exactly which ones should be overridden?\n For example if I try to pass configure --libexecdir=libexec to solve\nthe above issue, I get an error from configure:\n\n configure: error: expected an absolute directory name for --libexecdir: libexec\n\nAny info on how this is supposed to work, is welcome!\n"},{"id":"351688","messageId":"nycvar.QRO.7.76.6.1807041312150.75@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"97803ec8dae0a73bae301a37377b7b4a78f77e99.camel@mad-scientist.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-04T11:22:02Z","receivedAt":"2018-07-04T11:22:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Paul,\n\nOn Wed, 4 Jul 2018, Paul Smith wrote:\n\n> I was excited to see the RUNTIME_PREFIX for POSIX systems patchset go\n> by earlier this year.  Although I didn't see any mention of it being\n> included in the 2.18.0 release notes, it does appear that it was merged\n> in for this release.\n> \n> Has anyone else tried to get it working?  It doesn't appear to be\n> working properly for me so I'm not sure if I'm supposed to be doing\n> something different... I didn't see any documentation on it.\n\nIt is working (for ages) in the Git for Windows build.\n\n> Basically what happens is that I run configure with\n> --prefix=/my/install/path --with-gitconfig=etc/gitconfig\n> --with-gitattributes=etc/gitattributes.\n> \n> Then I run make with RUNTIME_PREFIX=YesPlease.\n\nAh. In Git for Windows, we do not use configure. I *think* this points to\nan incompatibility of the RUNTIME_PREFIX feature with our autoconf\nsupport, and this is a grand opportunity for you to step in and help.\n\nEssentially, what you will want to do is to implement a new configure\noption --with-runtime-prefix that then prevents the autoconf script from\nmunging the relative paths in the way it does.\n\n> When I look in the makefile, I see that the make variable gitexecdir is\n> initially properly set to libexec/git-core which is what I expect.\n> \n> However, later in the makefile we include the config.mak.autogen file,\n> which was generated from config.mk.in by configure.  In the .in file we\n> have this:\n> \n>  gitexecdir = @libexecdir@/git-core\n> \n> After configure gets done with it, this becomes:\n> \n>  gitexecdir = ${prefix}/libexec/git-core\n> \n> which is a fully-qualified path.  This means that exec-cmd.c is\n> compiled with -DGIT_EXEC_PATH=\"/my/install/path/libexec/git-core\" which\n> effectively disables RUNTIME_PREFIX, as the exec-cmd.c:system_prefix()\n> function always returns FALLBACK_RUNTIME_PREFIX since GIT_EXEC_PATH is\n> not a suffix of executable_dirname (once the install location has been\n> moved).\n\nRight.\n\nI am actually quite surprised that it builds for you, given this part of\nthe Makefile:\n\n-- snip --\nifdef RUNTIME_PREFIX\n\nifneq ($(filter /%,$(firstword $(gitexecdir_relative))),)\n$(error RUNTIME_PREFIX requires a relative gitexecdir, not: $(gitexecdir))\nendif\n\n[...]\n-- snap --\n\nI am also quite surprised that config.mk.in tries to set gitexecdir. But I\nguess that is for cases where you want to override it via --libexecdir?\n\n> I suppose we need to pass more configure options to reset paths; is\n> there information somewhere on exactly which ones should be overridden?\n>  For example if I try to pass configure --libexecdir=libexec to solve\n> the above issue, I get an error from configure:\n> \n>  configure: error: expected an absolute directory name for --libexecdir: libexec\n> \n> Any info on how this is supposed to work, is welcome!\n\nI just saw another thing:\n\n-- snip --\nexec-cmd.sp exec-cmd.s exec-cmd.o: GIT-PREFIX\nexec-cmd.sp exec-cmd.s exec-cmd.o: EXTRA_CPPFLAGS = \\\n        '-DGIT_EXEC_PATH=\"$(gitexecdir_SQ)\"' \\\n        '-DGIT_LOCALE_PATH=\"$(localedir_relative_SQ)\"' \\\n        '-DBINDIR=\"$(bindir_relative_SQ)\"' \\\n        '-DFALLBACK_RUNTIME_PREFIX=\"$(prefix_SQ)\"'\n-- snap --\n\nIs it possible that we should use `gitexecdir_relative_SQ` here instead?\nDoes that fix things for you?\n\nI Cc:ed Dan so he could correct my hunch that this GIT_EXEC_PATH\ndefinition needs to be fixed.\n\nCiao,\nJohannes\n"},{"id":"351709","messageId":"986185d30a0f09b4e2a9832d324a265cd3da7354.camel@mad-scientist.net","threadId":"48826","inReplyTo":"nycvar.QRO.7.76.6.1807041312150.75@tvgsbejvaqbjf.bet","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2018-07-05T15:36:38Z","receivedAt":"2018-07-05T16:42:53Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Wed, 2018-07-04 at 13:22 +0200, Johannes Schindelin wrote:\n> > Basically what happens is that I run configure with\n> > --prefix=/my/install/path --with-gitconfig=etc/gitconfig\n> > --with-gitattributes=etc/gitattributes.\n> > \n> > Then I run make with RUNTIME_PREFIX=YesPlease.\n> \n> Ah. In Git for Windows, we do not use configure. I *think* this\n> points to an incompatibility of the RUNTIME_PREFIX feature with our\n> autoconf support, and this is a grand opportunity for you to step in\n> and help.\n> \n> Essentially, what you will want to do is to implement a new configure\n> option --with-runtime-prefix that then prevents the autoconf script\n> from munging the relative paths in the way it does.\n\nFYI I was able to get this to work by overriding variables on the make\ncommand line, like this:\n\n  make ... RUNTIME_PREFIX=YesPlease \\\n      gitexecdir=libexec/git-core \\\n      template_dir=share/git-core/templates \\\n      sysconfdir=etc\n\nI agree a new autoconf option would be much simpler to use.  I'll think\nabout it as I happen to have some some experience in these areas ;) ...\nbut time is limited of course :).\n"},{"id":"351768","messageId":"nycvar.QRO.7.76.6.1807061059260.75@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"986185d30a0f09b4e2a9832d324a265cd3da7354.camel@mad-scientist.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-06T09:00:00Z","receivedAt":"2018-07-06T09:00:25Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Paul,\n\nOn Thu, 5 Jul 2018, Paul Smith wrote:\n\n> On Wed, 2018-07-04 at 13:22 +0200, Johannes Schindelin wrote:\n> > > Basically what happens is that I run configure with\n> > > --prefix=/my/install/path --with-gitconfig=etc/gitconfig\n> > > --with-gitattributes=etc/gitattributes.\n> > > \n> > > Then I run make with RUNTIME_PREFIX=YesPlease.\n> > \n> > Ah. In Git for Windows, we do not use configure. I *think* this\n> > points to an incompatibility of the RUNTIME_PREFIX feature with our\n> > autoconf support, and this is a grand opportunity for you to step in\n> > and help.\n> > \n> > Essentially, what you will want to do is to implement a new configure\n> > option --with-runtime-prefix that then prevents the autoconf script\n> > from munging the relative paths in the way it does.\n> \n> FYI I was able to get this to work by overriding variables on the make\n> command line, like this:\n> \n>   make ... RUNTIME_PREFIX=YesPlease \\\n>       gitexecdir=libexec/git-core \\\n>       template_dir=share/git-core/templates \\\n>       sysconfdir=etc\n> \n> I agree a new autoconf option would be much simpler to use.  I'll think\n> about it as I happen to have some some experience in these areas ;) ...\n\nI look forward to reviewing this...\n\n> but time is limited of course :).\n\nYep. Same here ;-)\n\nCiao,\nJohannes\n"},{"id":"351778","messageId":"CAD1RUU-4a_jV_JjozjXOR4bi+_7rFW_AjmHbbrw6NHJ77=oGkw@mail.gmail.com","threadId":"48826","inReplyTo":"nycvar.QRO.7.76.6.1807061059260.75@tvgsbejvaqbjf.bet","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Daniel Jacques","fromEmail":"dnj@google.com","sentAt":"2018-07-06T13:18:21Z","receivedAt":"2018-07-06T13:18:37Z","isPatch":false,"sender":{"key":"dnj@google.com","avatar":"https://avatars.githubusercontent.com/u/9965104?v=4"},"body":"Apologies for the delayed response - I've been out of town - and It\nlooks like Paul is already on the right track.\n\nJohannes: I believe the GIT_EXEC_PATH snipped that you listed is not\nincorrect. It's defined to \"gitexecdir_SQ\", and RUNTIME_PREFIX expects\n(and enforces, as you snipped) that this is a relative path in\nMakefile.\n\nOn non-RUNTIME_PREFIX builds, it should still be the absolute path, as\nthis is how Git self-locates, so using \"gitexecdir_SQ\" there makes\nsense to me.\n\nSo:\nRUNTIME_PREFIX=No, gitexecdir_SQ is absolute, GIT_EXEC_PATH is\nabsolute, used to find Git:\nhttps://github.com/git/git/blob/ccdcbd54c4475c2238b310f7113ab3075b5abc9c/exec-cmd.c#L281\nRUNTIME_PREFIX=YesPlease, gitexecdir_SQ is relative, GIT_EXEC_PATH is\nrelative and used to identify the search root of the Git installation:\nhttps://github.com/git/git/blob/ccdcbd54c4475c2238b310f7113ab3075b5abc9c/exec-cmd.c#L40\n\nThe dual-use is confusing, and it took me a few to walk back through\nhow it is employed in each scenario. For clarity's sake, it may be\nworth defining two variables and making one explicitly relative, but I\nthink it is functional as-is.\n\nPaul: I used \"config.mak\" to configure RUNTIME_PREFIX when I used it\nto the same effect:\nhttps://chromium.googlesource.com/infra/infra/+/ca729b99c1f82665b634ef2ff69d93c97dfcda99/recipes/recipe_modules/third_party_packages/git.py#78\n\nI forewent autoconf because I was concerned that the option was too\nobscure and the configuration too nuanced to be worth adding via flag,\nas RUNTIME_PREFIX requires some degree of path alignment and is fairly\nspecial-case. If you prefer autoconf, though, it sounds like a good\nthing to add, and I'm happy that you are finding the feature useful!\n\nCheers,\n-Dan\n\nOn Fri, Jul 6, 2018 at 5:00 AM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi Paul,\n>\n> On Thu, 5 Jul 2018, Paul Smith wrote:\n>\n> > On Wed, 2018-07-04 at 13:22 +0200, Johannes Schindelin wrote:\n> > > > Basically what happens is that I run configure with\n> > > > --prefix=/my/install/path --with-gitconfig=etc/gitconfig\n> > > > --with-gitattributes=etc/gitattributes.\n> > > >\n> > > > Then I run make with RUNTIME_PREFIX=YesPlease.\n> > >\n> > > Ah. In Git for Windows, we do not use configure. I *think* this\n> > > points to an incompatibility of the RUNTIME_PREFIX feature with our\n> > > autoconf support, and this is a grand opportunity for you to step in\n> > > and help.\n> > >\n> > > Essentially, what you will want to do is to implement a new configure\n> > > option --with-runtime-prefix that then prevents the autoconf script\n> > > from munging the relative paths in the way it does.\n> >\n> > FYI I was able to get this to work by overriding variables on the make\n> > command line, like this:\n> >\n> >   make ... RUNTIME_PREFIX=YesPlease \\\n> >       gitexecdir=libexec/git-core \\\n> >       template_dir=share/git-core/templates \\\n> >       sysconfdir=etc\n> >\n> > I agree a new autoconf option would be much simpler to use.  I'll think\n> > about it as I happen to have some some experience in these areas ;) ...\n>\n> I look forward to reviewing this...\n>\n> > but time is limited of course :).\n>\n> Yep. Same here ;-)\n>\n> Ciao,\n> Johannes\n"},{"id":"351887","messageId":"bf0d4f33701ec694917f2e710c3fb097085c8d69.camel@mad-scientist.net","threadId":"48826","inReplyTo":"CAD1RUU-4a_jV_JjozjXOR4bi+_7rFW_AjmHbbrw6NHJ77=oGkw@mail.gmail.com","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Paul Smith","fromEmail":"paul@mad-scientist.net","sentAt":"2018-07-08T18:52:03Z","receivedAt":"2018-07-08T19:01:48Z","isPatch":false,"sender":{"key":"paul@mad-scientist.net","avatar":"https://avatars.githubusercontent.com/u/109636?v=4"},"body":"On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote:\n> I forewent autoconf because I was concerned that the option was too\n> obscure and the configuration too nuanced to be worth adding via\n> flag, as RUNTIME_PREFIX requires some degree of path alignment and is\n> fairly special-case. If you prefer autoconf, though, it sounds like a\n> good thing to add, and I'm happy that you are finding the feature\n> useful!\n\nWell, far from obscure, I actually think that RUNTIME_PREFIX should be\nthe default behavior on all platforms.  In fact speaking for myself, I\nsee no value at all in the hardcoded path behavior and it could be\nremoved and RUNTIME_PREFIX be the only option and that would be fine\nwith me.\n\nThe only possible advantage I can see to the current default that you\ncan copy the Git binary alone somewhere else, but that's of very little\nvalue IMO: you could instead create a symbolic link or a two-line shell\nscript wrapper if you wanted to have \"git\" available outside of its\nnormal relation to the rest of the installation for some reason.\n\nThanks for making this work in any event, Daniel!\n"},{"id":"351894","messageId":"nycvar.QRO.7.76.6.1807082346140.75@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"bf0d4f33701ec694917f2e710c3fb097085c8d69.camel@mad-scientist.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-08T21:52:22Z","receivedAt":"2018-07-08T21:52:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Paul,\n\nOn Sun, 8 Jul 2018, Paul Smith wrote:\n\n> On Fri, 2018-07-06 at 09:18 -0400, Daniel Jacques wrote:\n> > I forewent autoconf because I was concerned that the option was too\n> > obscure and the configuration too nuanced to be worth adding via\n> > flag, as RUNTIME_PREFIX requires some degree of path alignment and is\n> > fairly special-case. If you prefer autoconf, though, it sounds like a\n> > good thing to add, and I'm happy that you are finding the feature\n> > useful!\n> \n> Well, far from obscure, I actually think that RUNTIME_PREFIX should be\n> the default behavior on all platforms.  In fact speaking for myself, I\n> see no value at all in the hardcoded path behavior and it could be\n> removed and RUNTIME_PREFIX be the only option and that would be fine\n> with me.\n> \n> The only possible advantage I can see to the current default that you\n> can copy the Git binary alone somewhere else, but that's of very little\n> value IMO: you could instead create a symbolic link or a two-line shell\n> script wrapper if you wanted to have \"git\" available outside of its\n> normal relation to the rest of the installation for some reason.\n\nIn theory, I agree with you, I would love for RUNTIME_PREFIX not even to\nbe needed.\n\nIn practice, however, a *loooong* time ago it was decided that it was okay\nto implement parts of Git as shell scripts, and when those shell scripts\nfinally became too many, in order not to clutter the `PATH`, they were\nmoved to the libexec/git-core/ directory.\n\nObviously, for this to work, Git needs to prefix the `PATH` variable\ninternally, and for that it has to know where that libexec/git-core/\ndirectory lives.\n\nNow, if you care to have a look at Dan's (and my) patches to implement\nRUNTIME_PREFIX so that it looks for a directory *relative to the Git\nbinary*, you will see that it is far from portable. In fact, it is very\ndefinitely not portable, and needs specific support for *every single\nsupported Operating System*. And while we covered a lot, we did not cover\nall of them.\n\nSo unfortunately, it is impossible to make it the default, I am afraid.\nUntil the time when we can ship a single `git` binary (which is sadly\nunlikely to happen, as there has been a *lot* of pushback against that\ne.g. on the grounds that having to (lazy-)load the cURL library adds a\ntiny bit to the startup time of the `git` binary).\n\nIt is all a bit complex, due to non-technical reasons.\n\nCiao,\nDscho\n"},{"id":"351999","messageId":"20180709195822.GA9000@sigill.intra.peff.net","threadId":"48826","inReplyTo":"nycvar.QRO.7.76.6.1807082346140.75@tvgsbejvaqbjf.bet","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-09T19:58:22Z","receivedAt":"2018-07-09T19:58:27Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jul 08, 2018 at 11:52:22PM +0200, Johannes Schindelin wrote:\n\n> Now, if you care to have a look at Dan's (and my) patches to implement\n> RUNTIME_PREFIX so that it looks for a directory *relative to the Git\n> binary*, you will see that it is far from portable. In fact, it is very\n> definitely not portable, and needs specific support for *every single\n> supported Operating System*. And while we covered a lot, we did not cover\n> all of them.\n> \n> So unfortunately, it is impossible to make it the default, I am afraid.\n\nWould it be reasonable to make RUNTIME_PREFIX the default on systems\nwhere we _do_ have that support? AFAIK there is no downside to having it\nenabled (minus a few syscalls to find the prefix, I suppose, but I\nassume that's negligible).\n\nI.e., a patch to config.mak.uname (and possibly better support for\n_disabling_ it, though I think \"make RUNTIME_PREFIX=\" would probably\nwork).\n\n-Peff\n"},{"id":"352011","messageId":"nycvar.QRO.7.76.6.1807092225120.75@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"20180709195822.GA9000@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-09T20:26:54Z","receivedAt":"2018-07-09T20:27:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Mon, 9 Jul 2018, Jeff King wrote:\n\n> On Sun, Jul 08, 2018 at 11:52:22PM +0200, Johannes Schindelin wrote:\n> \n> > Now, if you care to have a look at Dan's (and my) patches to implement\n> > RUNTIME_PREFIX so that it looks for a directory *relative to the Git\n> > binary*, you will see that it is far from portable. In fact, it is very\n> > definitely not portable, and needs specific support for *every single\n> > supported Operating System*. And while we covered a lot, we did not cover\n> > all of them.\n> > \n> > So unfortunately, it is impossible to make it the default, I am afraid.\n> \n> Would it be reasonable to make RUNTIME_PREFIX the default on systems\n> where we _do_ have that support? AFAIK there is no downside to having it\n> enabled (minus a few syscalls to find the prefix, I suppose, but I\n> assume that's negligible).\n> \n> I.e., a patch to config.mak.uname (and possibly better support for\n> _disabling_ it, though I think \"make RUNTIME_PREFIX=\" would probably\n> work).\n\nThe obvious downside is that we would be a lot more likely to break one\nside of the equation. At least right now, we have Git for Windows being a\nprime user of RUNTIME_PREFIX (so breakages should be caught relatively\nquickly), and macOS/Linux *not* being users of that feature (so breakages\nin the non-RUNTIME_PREFIX code paths should be caught even quicker). By\nturning on RUNTIME_PREFIX for the major platforms, the fringe platforms\nare even further out on their own.\n\nCiao,\nDscho\n"},{"id":"352026","messageId":"xmqq1sccce7q.fsf@gitster-ct.c.googlers.com","threadId":"48826","inReplyTo":"20180709195822.GA9000@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-09T21:05:13Z","receivedAt":"2018-07-09T21:05:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Sun, Jul 08, 2018 at 11:52:22PM +0200, Johannes Schindelin wrote:\n>\n>> Now, if you care to have a look at Dan's (and my) patches to implement\n>> RUNTIME_PREFIX so that it looks for a directory *relative to the Git\n>> binary*, you will see that it is far from portable. In fact, it is very\n>> definitely not portable, and needs specific support for *every single\n>> supported Operating System*. And while we covered a lot, we did not cover\n>> all of them.\n>> \n>> So unfortunately, it is impossible to make it the default, I am afraid.\n>\n> Would it be reasonable to make RUNTIME_PREFIX the default on systems\n> where we _do_ have that support? AFAIK there is no downside to having it\n> enabled (minus a few syscalls to find the prefix, I suppose, but I\n> assume that's negligible).\n>\n> I.e., a patch to config.mak.uname (and possibly better support for\n> _disabling_ it, though I think \"make RUNTIME_PREFIX=\" would probably\n> work).\n\nI think that is a sensible approach.\n\n\n\n"},{"id":"352058","messageId":"20180710022141.GC10248@sigill.intra.peff.net","threadId":"48826","inReplyTo":"nycvar.QRO.7.76.6.1807092225120.75@tvgsbejvaqbjf.bet","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-10T02:21:41Z","receivedAt":"2018-07-10T02:21:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 09, 2018 at 10:26:54PM +0200, Johannes Schindelin wrote:\n\n> > Would it be reasonable to make RUNTIME_PREFIX the default on systems\n> > where we _do_ have that support? AFAIK there is no downside to having it\n> > enabled (minus a few syscalls to find the prefix, I suppose, but I\n> > assume that's negligible).\n> > \n> > I.e., a patch to config.mak.uname (and possibly better support for\n> > _disabling_ it, though I think \"make RUNTIME_PREFIX=\" would probably\n> > work).\n> \n> The obvious downside is that we would be a lot more likely to break one\n> side of the equation. At least right now, we have Git for Windows being a\n> prime user of RUNTIME_PREFIX (so breakages should be caught relatively\n> quickly), and macOS/Linux *not* being users of that feature (so breakages\n> in the non-RUNTIME_PREFIX code paths should be caught even quicker). By\n> turning on RUNTIME_PREFIX for the major platforms, the fringe platforms\n> are even further out on their own.\n\nThat's true. On the other hand, we have a zillion compat features for\nfringe platforms already, so there already is an expectation that people\non those platforms would need to occasionally report and fix\nsystem-specific bugs. Perhaps thinking of it not as an feature to opt\ninto, but rather as a compat for \"your system has not caught up to the\nmodern world by implementing RUNTIME_PREFIX\" would encourage people on\nthose platforms to implement the necessary scaffolding.\n\nI also have a gut feeling that it is much easier for static-path devs to\nbreak RUNTIME_PREFIX folks, rather than the other way around, simply\nbecause RUNTIME_PREFIX has a lot more moving parts. But I admit that's\njust a feeling.\n\n-Peff\n"},{"id":"352059","messageId":"20180710035635.GA13459@sigill.intra.peff.net","threadId":"48826","inReplyTo":"20180709195822.GA9000@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-10T03:56:35Z","receivedAt":"2018-07-10T03:56:45Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 09, 2018 at 03:58:22PM -0400, Jeff King wrote:\n\n> On Sun, Jul 08, 2018 at 11:52:22PM +0200, Johannes Schindelin wrote:\n> \n> > Now, if you care to have a look at Dan's (and my) patches to implement\n> > RUNTIME_PREFIX so that it looks for a directory *relative to the Git\n> > binary*, you will see that it is far from portable. In fact, it is very\n> > definitely not portable, and needs specific support for *every single\n> > supported Operating System*. And while we covered a lot, we did not cover\n> > all of them.\n> > \n> > So unfortunately, it is impossible to make it the default, I am afraid.\n> \n> Would it be reasonable to make RUNTIME_PREFIX the default on systems\n> where we _do_ have that support? AFAIK there is no downside to having it\n> enabled (minus a few syscalls to find the prefix, I suppose, but I\n> assume that's negligible).\n\nBrainstorming a little more on \"what could be the possible downsides\".\n\nIf I understand correctly, the Linux implementation requires reading\nfrom /proc. So an executable that only did RUNTIME_PREFIX (with no\nfallback to static paths) would be unhappy inside a chroot or other\ncontainer that didn't mount /proc.\n\n-Peff\n"},{"id":"352066","messageId":"5b445ca6.TkV9Dj8T2KFinxZP%perryh@pluto.rain.com","threadId":"48826","inReplyTo":"20180710035635.GA13459@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Perry Hutchison","fromEmail":"perryh@pluto.rain.com","sentAt":"2018-07-10T07:13:42Z","receivedAt":"2018-07-10T07:58:08Z","isPatch":false,"sender":{"key":"perryh@pluto.rain.com","avatar":null},"body":"Jeff King <peff@peff.net> wrote:\n\n> If I understand correctly, the Linux implementation requires reading\n> from /proc. So an executable that only did RUNTIME_PREFIX (with no\n> fallback to static paths) would be unhappy inside a chroot or other\n> container that didn't mount /proc.\n\nIf we need /proc, wouldn't we _already_ be unhappy inside a chroot\nthat didn't mount /proc, even _with_ fallback to static paths?\nLast I knew, the whole point of chroots/containers/jails/etc. was to\nprevent access, from a process running inside the container, to any\npart of the FS that's outside of the container.\n"},{"id":"352085","messageId":"nycvar.QRO.7.76.6.1807101339370.75@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"20180710022141.GC10248@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-10T11:40:01Z","receivedAt":"2018-07-10T11:40:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Mon, 9 Jul 2018, Jeff King wrote:\n\n> On Mon, Jul 09, 2018 at 10:26:54PM +0200, Johannes Schindelin wrote:\n> \n> > > Would it be reasonable to make RUNTIME_PREFIX the default on systems\n> > > where we _do_ have that support? AFAIK there is no downside to having it\n> > > enabled (minus a few syscalls to find the prefix, I suppose, but I\n> > > assume that's negligible).\n> > > \n> > > I.e., a patch to config.mak.uname (and possibly better support for\n> > > _disabling_ it, though I think \"make RUNTIME_PREFIX=\" would probably\n> > > work).\n> > \n> > The obvious downside is that we would be a lot more likely to break one\n> > side of the equation. At least right now, we have Git for Windows being a\n> > prime user of RUNTIME_PREFIX (so breakages should be caught relatively\n> > quickly), and macOS/Linux *not* being users of that feature (so breakages\n> > in the non-RUNTIME_PREFIX code paths should be caught even quicker). By\n> > turning on RUNTIME_PREFIX for the major platforms, the fringe platforms\n> > are even further out on their own.\n> \n> That's true. On the other hand, we have a zillion compat features for\n> fringe platforms already, so there already is an expectation that people\n> on those platforms would need to occasionally report and fix\n> system-specific bugs. Perhaps thinking of it not as an feature to opt\n> into, but rather as a compat for \"your system has not caught up to the\n> modern world by implementing RUNTIME_PREFIX\" would encourage people on\n> those platforms to implement the necessary scaffolding.\n> \n> I also have a gut feeling that it is much easier for static-path devs to\n> break RUNTIME_PREFIX folks, rather than the other way around, simply\n> because RUNTIME_PREFIX has a lot more moving parts. But I admit that's\n> just a feeling.\n\nYour gut feeling comes from a lot of experience that I trust. So I'll go\nwith it, too.\n\nCiao,\nDscho\n"},{"id":"352111","messageId":"20180710140310.GA9246@sigill.intra.peff.net","threadId":"48826","inReplyTo":"5b445ca6.TkV9Dj8T2KFinxZP%perryh@pluto.rain.com","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2018-07-10T14:03:10Z","receivedAt":"2018-07-10T14:03:16Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jul 10, 2018 at 12:13:42AM -0700, Perry Hutchison wrote:\n\n> Jeff King <peff@peff.net> wrote:\n> \n> > If I understand correctly, the Linux implementation requires reading\n> > from /proc. So an executable that only did RUNTIME_PREFIX (with no\n> > fallback to static paths) would be unhappy inside a chroot or other\n> > container that didn't mount /proc.\n> \n> If we need /proc, wouldn't we _already_ be unhappy inside a chroot\n> that didn't mount /proc, even _with_ fallback to static paths?\n> Last I knew, the whole point of chroots/containers/jails/etc. was to\n> prevent access, from a process running inside the container, to any\n> part of the FS that's outside of the container.\n\nMy point is that aside from RUNTIME_PREFIX, we don't need /proc. So\nsomebody who currently builds Git with a static path like\n\"/usr/libexec/git-core\" and runs it inside a chroot will be just fine as\nlong as /usr/libexec/git-core is available at that name inside the\nchroot. But if the build starts relying on RUNTIME_PREFIX, it's going to\nregress their case.\n\nI'm not sure how hypothetical this is. A lot of Debian tools use chroots\nto build packages for specific releases by basically installing the\ndistro inside the chroot. I don't know whether /proc is available in\nthose chroots or not. If not, then I suspect builds that rely on\ninstalling Git inside the chroot are going to break.\n\n+cc Jonathan, who maintains the Git package for Debian, and can probably\nsay immediately whether I am way off base. ;)\n\n-Peff\n"},{"id":"352112","messageId":"CAD1RUU8pT-3GKN4qRjysi+re+AKF4eB+VEDr+GzMW_4=E4uftQ@mail.gmail.com","threadId":"48826","inReplyTo":"nycvar.QRO.7.76.6.1807101339370.75@tvgsbejvaqbjf.bet","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Daniel Jacques","fromEmail":"dnj@google.com","sentAt":"2018-07-10T14:03:00Z","receivedAt":"2018-07-10T14:03:19Z","isPatch":false,"sender":{"key":"dnj@google.com","avatar":"https://avatars.githubusercontent.com/u/9965104?v=4"},"body":"Perry Hutchison wrote:\n\n> If we need /proc, wouldn't we _already_ be unhappy inside a chroot\n> that didn't mount /proc, even _with_ fallback to static paths?\n> Last I knew, the whole point of chroots/containers/jails/etc. was to\n> prevent access, from a process running inside the container, to any\n> part of the FS that's outside of the container.\n\nYep. The code also allows for use of \"argv[0]\", but that has its own set of\nproblems. These were previously covered in the discussions leading up to\nthe patch landing, but to summarize, \"argv[0]\" can be completely manipulated\nby the calling process, whimsically or in response to constraints such as\nlinks, and is wholly unreliable for self-location.\n\nOther kernels have their own behaviors with respect to path self-location,\nand none seem to be straightforward. This link seems to have a good\nrundown of the details and differences:\n\nhttps://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe\n\nAll things considered, I think executable path self-location is markedly more\nfragile than using static paths, both with increased dependencies and added\ninconsistent behavior and limitations, and should not be the default\non any platform.\n\nBoth Johannes' original RUNTIME_PREFIX implementation for Windows and the\nLinux/etc. expansions that I did were written to serve constrained special case\ndeployments. In that capacity, they can be really useful, as the fragility is\nmanaged by their respective environments.\n\nMy particular use case served the purpose of building Git once and deploying\nit via archive on other systems. This capability requires the additional work of\nbuilding portable versions of Git's dependencies and their associated\nresources, and statically linking everything together.\n\nThis is a lot more portability than the conventional user requires, and also\nnecessitates a significantly more complex build process. However, making Git\nitself portable via RUNTIME_PREFIX without similar work on its dependencies\nlimits the usefulness of that portability, since it's still bound to\nthe system's\nlibraries and their resources.\n\nCheers,\n-Dan\n"},{"id":"352125","messageId":"xmqqefgb9iow.fsf@gitster-ct.c.googlers.com","threadId":"48826","inReplyTo":"CAD1RUU8pT-3GKN4qRjysi+re+AKF4eB+VEDr+GzMW_4=E4uftQ@mail.gmail.com","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-07-10T16:09:03Z","receivedAt":"2018-07-10T16:09:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Jacques <dnj@google.com> writes:\n\n> All things considered, I think executable path self-location is markedly more\n> fragile than using static paths, both with increased dependencies and added\n> inconsistent behavior and limitations, and should not be the default\n> on any platform.\n>\n> Both Johannes' original RUNTIME_PREFIX implementation for Windows and the\n> Linux/etc. expansions that I did were written to serve constrained special case\n> deployments. In that capacity, they can be really useful, as the fragility is\n> managed by their respective environments.\n\nWow, an original author of a non-trivial feature who does not push\nhis own creation to be used everywhere and instead cautions against\nblindly using it?  \n\nThat sort of restraint is a rare trait to be commended.  Thanks for\ninjeting a doze of sanity.\n\n"},{"id":"352187","messageId":"20180710222005.GP14196@aiede.svl.corp.google.com","threadId":"48826","inReplyTo":"20180710140310.GA9246@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-07-10T22:20:05Z","receivedAt":"2018-07-10T22:20:10Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJeff King wrote:\n\n> My point is that aside from RUNTIME_PREFIX, we don't need /proc. So\n> somebody who currently builds Git with a static path like\n> \"/usr/libexec/git-core\" and runs it inside a chroot will be just fine as\n> long as /usr/libexec/git-core is available at that name inside the\n> chroot. But if the build starts relying on RUNTIME_PREFIX, it's going to\n> regress their case.\n>\n> I'm not sure how hypothetical this is. A lot of Debian tools use chroots\n> to build packages for specific releases by basically installing the\n> distro inside the chroot. I don't know whether /proc is available in\n> those chroots or not. If not, then I suspect builds that rely on\n> installing Git inside the chroot are going to break.\n>\n> +cc Jonathan, who maintains the Git package for Debian, and can probably\n> say immediately whether I am way off base. ;)\n\nThe chroots typically have /proc.\n\nVarious libc features also count on /proc being mounted, though in\ngeneral libc tries to handle the case when it isn't mounted\ngracefully.  Similarly, various features of other tools (like bash's\nsupport for <(echo hi)) also rely on /proc.\n\nIf this is the main obstacle to enabling RUNTIME_PREFIX by default,\none option would be to make RUNTIME_PREFIX fall back to a hard-coded\npath when and only when git is not able to find the path from which it\nwas run.  That would increase complexity, though, so I am not thrilled\nwith the idea.\n\nI might try enabling RUNTIME_PREFIX in Debian experimental's git and\nseeing what breaks. ;-)\n\nThanks,\nJonathan\n"},{"id":"352188","messageId":"20180710222131.GQ14196@aiede.svl.corp.google.com","threadId":"48826","inReplyTo":"20180710222005.GP14196@aiede.svl.corp.google.com","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-07-10T22:21:31Z","receivedAt":"2018-07-10T22:21:35Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"A quick correction:\n\nJonathan Nieder wrote:\n\n>              Similarly, various features of other tools (like bash's\n> support for <(echo hi)) also rely on /proc.\n\nThat relies on /dev/fd, not /proc, but same idea.\n\nTools like \"ps\" rely on /proc.\n\nSorry for the noise,\nJonathan\n"},{"id":"352554","messageId":"20180714205132.GH1042117@genre.crustytoothpaste.net","threadId":"48826","inReplyTo":"20180710140310.GA9246@sigill.intra.peff.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-07-14T20:51:32Z","receivedAt":"2018-07-14T20:52:40Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Tue, Jul 10, 2018 at 10:03:10AM -0400, Jeff King wrote:\n> My point is that aside from RUNTIME_PREFIX, we don't need /proc. So\n> somebody who currently builds Git with a static path like\n> \"/usr/libexec/git-core\" and runs it inside a chroot will be just fine as\n> long as /usr/libexec/git-core is available at that name inside the\n> chroot. But if the build starts relying on RUNTIME_PREFIX, it's going to\n> regress their case.\n\nI will say that at cPanel, we have a configuration where end users can\nend up inside a mount namespace without /proc (depending on the\npreferences of the administrator).  However, it's easy enough for us to\nsimply build without RUNTIME_PREFIX if necessary.\n\nIf we turn it on by default, it would be nice if we documented (maybe in\nthe Makefile) that it requires /proc on Linux for the benefit of other\npeople who might be in a similar situation.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"352754","messageId":"nycvar.QRO.7.76.6.1807171144350.71@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"20180710222005.GP14196@aiede.svl.corp.google.com","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-17T09:45:44Z","receivedAt":"2018-07-17T09:46:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Jonathan,\n\n[had to drop Perry Hutchinson, as the email address is apparently invalid,\nand I only realized now that I never sent this out.]\n\nOn Tue, 10 Jul 2018, Jonathan Nieder wrote:\n\n> If this [/proc issue] is the main obstacle to enabling RUNTIME_PREFIX by\n> default, one option would be to make RUNTIME_PREFIX fall back to a\n> hard-coded path when and only when git is not able to find the path from\n> which it was run.\n\nThat is already the case. Look for FALLBACK_RUNTIME_PREFIX in the code.\n\nCiao,\nDscho\n"},{"id":"352858","messageId":"nycvar.QRO.7.76.6.1807181418120.71@tvgsbejvaqbjf.bet","threadId":"48826","inReplyTo":"20180714205132.GH1042117@genre.crustytoothpaste.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-07-18T12:18:44Z","receivedAt":"2018-07-18T12:19:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\n[dropping Perry's non-working email address again]\n\nOn Sat, 14 Jul 2018, brian m. carlson wrote:\n\n> On Tue, Jul 10, 2018 at 10:03:10AM -0400, Jeff King wrote:\n> > My point is that aside from RUNTIME_PREFIX, we don't need /proc. So\n> > somebody who currently builds Git with a static path like\n> > \"/usr/libexec/git-core\" and runs it inside a chroot will be just fine as\n> > long as /usr/libexec/git-core is available at that name inside the\n> > chroot. But if the build starts relying on RUNTIME_PREFIX, it's going to\n> > regress their case.\n> \n> I will say that at cPanel, we have a configuration where end users can\n> end up inside a mount namespace without /proc (depending on the\n> preferences of the administrator).  However, it's easy enough for us to\n> simply build without RUNTIME_PREFIX if necessary.\n> \n> If we turn it on by default, it would be nice if we documented (maybe in\n> the Makefile) that it requires /proc on Linux for the benefit of other\n> people who might be in a similar situation.\n\nIs there *really* no other way on Linux to figure out the absolute path of\nthe current executable than to open a pseudo file in the `/proc` file\nsystem?\n\nCiao,\nJohannes\n"},{"id":"353095","messageId":"20180719222613.GA7066@genre.crustytoothpaste.net","threadId":"48826","inReplyTo":"nycvar.QRO.7.76.6.1807181418120.71@tvgsbejvaqbjf.bet","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2018-07-19T22:26:13Z","receivedAt":"2018-07-19T22:26:22Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On Wed, Jul 18, 2018 at 02:18:44PM +0200, Johannes Schindelin wrote:\n> On Sat, 14 Jul 2018, brian m. carlson wrote:\n> > I will say that at cPanel, we have a configuration where end users can\n> > end up inside a mount namespace without /proc (depending on the\n> > preferences of the administrator).  However, it's easy enough for us to\n> > simply build without RUNTIME_PREFIX if necessary.\n> > \n> > If we turn it on by default, it would be nice if we documented (maybe in\n> > the Makefile) that it requires /proc on Linux for the benefit of other\n> > people who might be in a similar situation.\n> \n> Is there *really* no other way on Linux to figure out the absolute path of\n> the current executable than to open a pseudo file in the `/proc` file\n> system?\n\nNope, not that I'm aware of.  You have to read the destination of\nthe /proc/PID/exe symlink.\n-- \nbrian m. carlson: Houston, Texas, US\nOpenPGP: https://keybase.io/bk2204\n"},{"id":"353124","messageId":"fc1c6b0b-e7a5-cbde-d927-8c1e1c4e9f11@jeffhostetler.com","threadId":"48826","inReplyTo":"20180719222613.GA7066@genre.crustytoothpaste.net","subject":"Re: Git 2.18: RUNTIME_PREFIX... is it working?","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2018-07-20T14:29:01Z","receivedAt":"2018-07-20T14:29:06Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 7/19/2018 6:26 PM, brian m. carlson wrote:\n> On Wed, Jul 18, 2018 at 02:18:44PM +0200, Johannes Schindelin wrote:\n>> On Sat, 14 Jul 2018, brian m. carlson wrote:\n>>> I will say that at cPanel, we have a configuration where end users can\n>>> end up inside a mount namespace without /proc (depending on the\n>>> preferences of the administrator).  However, it's easy enough for us to\n>>> simply build without RUNTIME_PREFIX if necessary.\n>>>\n>>> If we turn it on by default, it would be nice if we documented (maybe in\n>>> the Makefile) that it requires /proc on Linux for the benefit of other\n>>> people who might be in a similar situation.\n>>\n>> Is there *really* no other way on Linux to figure out the absolute path of\n>> the current executable than to open a pseudo file in the `/proc` file\n>> system?\n> \n> Nope, not that I'm aware of.  You have to read the destination of\n> the /proc/PID/exe symlink.\n> \n\nGetting the full path of the current executable is a very Windows thing.\nOn most Unix-based systems it just isn't possible (even if Linux does\nhave the /proc thing).  Think about hard-links, for example.  There just\nisn't a single canonical pathname for an inode.\n\nJeff\n"}]}