Volume XXII, number 279Tuesday, October 6, 2026Latest message 1 hour ago

The Git List

News and archive of git@vger.kernel.org, since April 2005

patchexec_cmd: RUNTIME_PREFIX on OpenBSD systems

4 messages between Sep 17, 2026 and Sep 21, 2026, from Brad Smith, Junio C Hamano.

Plain Markdown or JSON for tools and agents. Diffs are folded; open one to read it.

Brad SmithSep 17, 2026, 03:40 UTC on lore
Enable Git to resolve its own binary location using getexecpath().
Signed-off-by: Brad Smith <brad@comstyle.com>
---
 Makefile         |  7 +++++++
 config.mak.uname |  3 +++
 exec-cmd.c       | 24 ++++++++++++++++++++++++
 3 files changed, 34 insertions(+)
Show changes to 3 files +34 −0

Makefile, config.mak.uname, exec-cmd.c

diff --git a/Makefile b/Makefile
index d4b775953d..9e3d37b5b4 100644
--- a/Makefile
+++ b/Makefile
@@ -378,6 +378,9 @@ include shared.mak
 # Perl scripts to use a modified entry point header allowing them to resolve
 # support files at runtime.
 #
+# When using RUNTIME_PREFIX, define HAVE_GETEXECPATH if your platform supports
+# the getexecpath() function.
+#
 # When using RUNTIME_PREFIX, define HAVE_BSD_KERN_PROC_SYSCTL if your platform
 # supports the KERN_PROC BSD sysctl function.
 #
@@ -2356,6 +2359,10 @@ endif
 
 ifdef RUNTIME_PREFIX
 
+        ifdef HAVE_GETEXECPATH
+		BASIC_CFLAGS += -DHAVE_GETEXECPATH
+        endif
+
         ifdef HAVE_BSD_KERN_PROC_SYSCTL
 		BASIC_CFLAGS += -DHAVE_BSD_KERN_PROC_SYSCTL
         endif
diff --git a/config.mak.uname b/config.mak.uname
index e28870434d..270aff1772 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -343,6 +343,9 @@ ifeq ($(uname_S),OpenBSD)
 	CSPRNG_METHOD = arc4random
 	FREAD_READS_DIRECTORIES = UnfortunatelyYes
 	FILENO_IS_A_MACRO = UnfortunatelyYes
+	ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 8 && echo 1),1)
+		HAVE_GETEXECPATH = YesPlease
+	endif
 endif
 ifeq ($(uname_S),MirBSD)
 	NO_STRCASESTR = YesPlease
diff --git a/exec-cmd.c b/exec-cmd.c
index 507e67d528..5251da4229 100644
--- a/exec-cmd.c
+++ b/exec-cmd.c
@@ -129,6 +129,26 @@ static int git_get_exec_path_bsd_sysctl(struct strbuf *buf)
 }
 #endif /* HAVE_BSD_KERN_PROC_SYSCTL */
 
+#ifdef HAVE_GETEXECPATH
+/*
+ * Resolves the executable path using getexecpath(3).
+ *
+ * Returns 0 on success, -1 on failure.
+ */
+static int git_get_exec_path_getexecpath(struct strbuf *buf)
+{
+	char path[PATH_MAX];
+	if (getexecpath(path, sizeof(path)) == 0) {
+		trace_printf(
+			"trace: resolved executable path from getexecpath: %s\n",
+			path);
+		strbuf_addstr(buf, path);
+		return 0;
+	}
+	return -1;
+}
+#endif /* HAVE_GETEXECPATH */
+
 #ifdef HAVE_NS_GET_EXECUTABLE_PATH
 /*
  * Resolves the executable path by querying Darwin application stack.
@@ -209,6 +229,10 @@ static int git_get_exec_path(struct strbuf *buf, const char *argv0)
 	 * after the first successful method.
 	 */
 	if (
+#ifdef HAVE_GETEXECPATH
+		git_get_exec_path_getexecpath(buf) &&
+#endif /* HAVE_GETEXECPATH */
+
 #ifdef HAVE_BSD_KERN_PROC_SYSCTL
 		git_get_exec_path_bsd_sysctl(buf) &&
 #endif /* HAVE_BSD_KERN_PROC_SYSCTL */
-- 
2.55.0
Junio C HamanoSep 17, 2026, 13:45 UTC in reply to Brad Smith on lore

Re: [PATCH] exec_cmd: RUNTIME_PREFIX on OpenBSD systems

Brad Smith <brad@comstyle.com> writes:
> Enable Git to resolve its own binary location using getexecpath().

That may not be incorrect information per-se, but lacks critical bits. Natural initial questions that come to my mind are...

    Why would one want to use getexecpath() over whatever OpenBSD
    ports of Git have been using happily?  Is the old way being
    removed?  Is the new way being more accurate?  In what
    situations does the difference matter?  Is everybody on OpenBSD
    able to use this new function?  Do only certain, and/or
    presumably later, verions of OpenBSD have it?  How widely is it
    available?  How long has it been available?

Your proposed commit log messages do not answer any of these questions, but it should. The title can also use a bit of tweak to identify which versions of OpenBSD this patch is relevant.

Show 88 quoted lines
> Signed-off-by: Brad Smith <brad@comstyle.com>
> ---
>  Makefile         |  7 +++++++
>  config.mak.uname |  3 +++
>  exec-cmd.c       | 24 ++++++++++++++++++++++++
>  3 files changed, 34 insertions(+)
>
> diff --git a/Makefile b/Makefile
> index d4b775953d..9e3d37b5b4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -378,6 +378,9 @@ include shared.mak
>  # Perl scripts to use a modified entry point header allowing them to resolve
>  # support files at runtime.
>  #
> +# When using RUNTIME_PREFIX, define HAVE_GETEXECPATH if your platform supports
> +# the getexecpath() function.
> +#
>  # When using RUNTIME_PREFIX, define HAVE_BSD_KERN_PROC_SYSCTL if your platform
>  # supports the KERN_PROC BSD sysctl function.
>  #
> @@ -2356,6 +2359,10 @@ endif
>  
>  ifdef RUNTIME_PREFIX
>  
> +        ifdef HAVE_GETEXECPATH
> +		BASIC_CFLAGS += -DHAVE_GETEXECPATH
> +        endif
> +
>          ifdef HAVE_BSD_KERN_PROC_SYSCTL
>  		BASIC_CFLAGS += -DHAVE_BSD_KERN_PROC_SYSCTL
>          endif
> diff --git a/config.mak.uname b/config.mak.uname
> index e28870434d..270aff1772 100644
> --- a/config.mak.uname
> +++ b/config.mak.uname
> @@ -343,6 +343,9 @@ ifeq ($(uname_S),OpenBSD)
>  	CSPRNG_METHOD = arc4random
>  	FREAD_READS_DIRECTORIES = UnfortunatelyYes
>  	FILENO_IS_A_MACRO = UnfortunatelyYes
> +	ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 8 && echo 1),1)
> +		HAVE_GETEXECPATH = YesPlease
> +	endif
>  endif
>  ifeq ($(uname_S),MirBSD)
>  	NO_STRCASESTR = YesPlease
> diff --git a/exec-cmd.c b/exec-cmd.c
> index 507e67d528..5251da4229 100644
> --- a/exec-cmd.c
> +++ b/exec-cmd.c
> @@ -129,6 +129,26 @@ static int git_get_exec_path_bsd_sysctl(struct strbuf *buf)
>  }
>  #endif /* HAVE_BSD_KERN_PROC_SYSCTL */
>  
> +#ifdef HAVE_GETEXECPATH
> +/*
> + * Resolves the executable path using getexecpath(3).
> + *
> + * Returns 0 on success, -1 on failure.
> + */
> +static int git_get_exec_path_getexecpath(struct strbuf *buf)
> +{
> +	char path[PATH_MAX];
> +	if (getexecpath(path, sizeof(path)) == 0) {
> +		trace_printf(
> +			"trace: resolved executable path from getexecpath: %s\n",
> +			path);
> +		strbuf_addstr(buf, path);
> +		return 0;
> +	}
> +	return -1;
> +}
> +#endif /* HAVE_GETEXECPATH */
> +
>  #ifdef HAVE_NS_GET_EXECUTABLE_PATH
>  /*
>   * Resolves the executable path by querying Darwin application stack.
> @@ -209,6 +229,10 @@ static int git_get_exec_path(struct strbuf *buf, const char *argv0)
>  	 * after the first successful method.
>  	 */
>  	if (
> +#ifdef HAVE_GETEXECPATH
> +		git_get_exec_path_getexecpath(buf) &&
> +#endif /* HAVE_GETEXECPATH */
> +
>  #ifdef HAVE_BSD_KERN_PROC_SYSCTL
>  		git_get_exec_path_bsd_sysctl(buf) &&
>  #endif /* HAVE_BSD_KERN_PROC_SYSCTL */
Brad SmithSep 21, 2026, 02:10 UTC in reply to Junio C Hamano on lore

Re: [PATCH] exec_cmd: RUNTIME_PREFIX on OpenBSD systems

On 2026-09-17 9:45 a.m., Junio C Hamano wrote:
Show 13 quoted lines
> Brad Smith <brad@comstyle.com> writes:
>
>> Enable Git to resolve its own binary location using getexecpath().
> That may not be incorrect information per-se, but lacks critical
> bits.  Natural initial questions that come to my mind are...
>
>      Why would one want to use getexecpath() over whatever OpenBSD
>      ports of Git have been using happily?  Is the old way being
>      removed?  Is the new way being more accurate?  In what
>      situations does the difference matter?  Is everybody on OpenBSD
>      able to use this new function?  Do only certain, and/or
>      presumably later, verions of OpenBSD have it?  How widely is it
>      available?  How long has it been available?

It's a long awaited API for such functionality on OpenBSD. Otherwise there hasn't really been a means of doing so and one which has been using happily. The proper API I would say is one which works and is more accurate. One which works the same everywhere where as the pile of hacks has different results and not happily either.

The API is new. The config.mak.uname check looks for 8.0 and newer.
Show 92 quoted lines
> Your proposed commit log messages do not answer any of these
> questions, but it should.  The title can also use a bit of tweak to
> identify which versions of OpenBSD this patch is relevant.
>
>> Signed-off-by: Brad Smith <brad@comstyle.com>
>> ---
>>   Makefile         |  7 +++++++
>>   config.mak.uname |  3 +++
>>   exec-cmd.c       | 24 ++++++++++++++++++++++++
>>   3 files changed, 34 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index d4b775953d..9e3d37b5b4 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -378,6 +378,9 @@ include shared.mak
>>   # Perl scripts to use a modified entry point header allowing them to resolve
>>   # support files at runtime.
>>   #
>> +# When using RUNTIME_PREFIX, define HAVE_GETEXECPATH if your platform supports
>> +# the getexecpath() function.
>> +#
>>   # When using RUNTIME_PREFIX, define HAVE_BSD_KERN_PROC_SYSCTL if your platform
>>   # supports the KERN_PROC BSD sysctl function.
>>   #
>> @@ -2356,6 +2359,10 @@ endif
>>   
>>   ifdef RUNTIME_PREFIX
>>   
>> +        ifdef HAVE_GETEXECPATH
>> +		BASIC_CFLAGS += -DHAVE_GETEXECPATH
>> +        endif
>> +
>>           ifdef HAVE_BSD_KERN_PROC_SYSCTL
>>   		BASIC_CFLAGS += -DHAVE_BSD_KERN_PROC_SYSCTL
>>           endif
>> diff --git a/config.mak.uname b/config.mak.uname
>> index e28870434d..270aff1772 100644
>> --- a/config.mak.uname
>> +++ b/config.mak.uname
>> @@ -343,6 +343,9 @@ ifeq ($(uname_S),OpenBSD)
>>   	CSPRNG_METHOD = arc4random
>>   	FREAD_READS_DIRECTORIES = UnfortunatelyYes
>>   	FILENO_IS_A_MACRO = UnfortunatelyYes
>> +	ifeq ($(shell test "`expr "$(uname_R)" : '\([0-9][0-9]*\)\.'`" -ge 8 && echo 1),1)
>> +		HAVE_GETEXECPATH = YesPlease
>> +	endif
>>   endif
>>   ifeq ($(uname_S),MirBSD)
>>   	NO_STRCASESTR = YesPlease
>> diff --git a/exec-cmd.c b/exec-cmd.c
>> index 507e67d528..5251da4229 100644
>> --- a/exec-cmd.c
>> +++ b/exec-cmd.c
>> @@ -129,6 +129,26 @@ static int git_get_exec_path_bsd_sysctl(struct strbuf *buf)
>>   }
>>   #endif /* HAVE_BSD_KERN_PROC_SYSCTL */
>>   
>> +#ifdef HAVE_GETEXECPATH
>> +/*
>> + * Resolves the executable path using getexecpath(3).
>> + *
>> + * Returns 0 on success, -1 on failure.
>> + */
>> +static int git_get_exec_path_getexecpath(struct strbuf *buf)
>> +{
>> +	char path[PATH_MAX];
>> +	if (getexecpath(path, sizeof(path)) == 0) {
>> +		trace_printf(
>> +			"trace: resolved executable path from getexecpath: %s\n",
>> +			path);
>> +		strbuf_addstr(buf, path);
>> +		return 0;
>> +	}
>> +	return -1;
>> +}
>> +#endif /* HAVE_GETEXECPATH */
>> +
>>   #ifdef HAVE_NS_GET_EXECUTABLE_PATH
>>   /*
>>    * Resolves the executable path by querying Darwin application stack.
>> @@ -209,6 +229,10 @@ static int git_get_exec_path(struct strbuf *buf, const char *argv0)
>>   	 * after the first successful method.
>>   	 */
>>   	if (
>> +#ifdef HAVE_GETEXECPATH
>> +		git_get_exec_path_getexecpath(buf) &&
>> +#endif /* HAVE_GETEXECPATH */
>> +
>>   #ifdef HAVE_BSD_KERN_PROC_SYSCTL
>>   		git_get_exec_path_bsd_sysctl(buf) &&
>>   #endif /* HAVE_BSD_KERN_PROC_SYSCTL */
Junio C HamanoSep 21, 2026, 16:57 UTC in reply to Brad Smith on lore

Re: [PATCH] exec_cmd: RUNTIME_PREFIX on OpenBSD systems

Brad Smith <brad@comstyle.com> writes:
Show 22 quoted lines
> On 2026-09-17 9:45 a.m., Junio C Hamano wrote:
>> Brad Smith <brad@comstyle.com> writes:
>>
>>> Enable Git to resolve its own binary location using getexecpath().
>> That may not be incorrect information per-se, but lacks critical
>> bits.  Natural initial questions that come to my mind are...
>>
>>      Why would one want to use getexecpath() over whatever OpenBSD
>>      ports of Git have been using happily?  Is the old way being
>>      removed?  Is the new way being more accurate?  In what
>>      situations does the difference matter?  Is everybody on OpenBSD
>>      able to use this new function?  Do only certain, and/or
>>      presumably later, verions of OpenBSD have it?  How widely is it
>>      available?  How long has it been available?
>
> It's a long awaited API for such functionality on OpenBSD. Otherwise there
> hasn't really been a means of doing so and one which has been using happily.
> The proper API I would say is one which works and is more accurate. One
> which works the same everywhere where as the pile of hacks has different
> results and not happily either.
>
> The API is new. The config.mak.uname check looks for 8.0 and newer.

OK, all of the above were missing from the proposed log message that should be placed when v2 patch is prepared. They've happily been using argv[0] as an approximate (which may be OK as long as we do not lie to ourselves but not as nice), and now they are going to have a proper syscall for the information, finally. You would also need to answer the last few questions I asked in the proposed log message of v2, but I thought 8.0 is not yet released?

Thanks.

Back to recent threads