[PATCH] build: fix FreeBSD build when sysinfo compat library installed

[PATCH] build: fix FreeBSD build when sysinfo compat library installed

[Ramsay Jones]

Commit 50dec7c566 ("config.mak.uname: add sysinfo() configuration for
cygwin", 2025-04-17) and later commit 187ce0222f ("configure.ac: upgrade
to a compilation check for sysinfo", 2025-05-19) added a 'sysinfo()'
check to the autoconf build.

The FreeBSD system has an optional sysinfo compatibility library, used
to assist in porting software, which causes the build to fail when it
is installed. The reason for the failure is the lack of '-lsysinfo'
during the linking step.

Several solutions were considered:

  - add an 'linking' check to configure.ac in order to determine the
    need to link a separate library (-lsysinfo). (This would require
    a similar change to meson.build).

  - change the order of the preprocessor conditionals in the total_ram()
    function in 'builtin/gc.c', so that the *BSD sysctl() function
    (in the HAVE_BSD_SYSCTL block) takes priority over the sysinfo()
    function (in the HAVE_SYSINFO block).

  - suppress the setting of HAVE_SYSINFO when HAVE_BSD_SYSCTL has been
    defined (in both configure.ac and meson.build).

The first solution above, while simple, adds unnecessary code (the
sysinfo compat function is likely implemented using sysctl() anyway)
when git is happy to use sysctl() on *BSD systems.

The second solution would only be required by the autoconf and meson
build systems, the Makefile already sets the build variables to the
required values (since they are not 'auto-detected').

Here we opt for the final solution above, since it only requires that
we prioritise the 'auto-detected' build variables in the autoconf and
meson builds.

In order to fix the FreeBSD build, move the sysinfo() check after the
determination of the HAVE_BSD_SYSCTL build variable, suppressing the
setting of HAVE_SYSINFO if HAVE_BSD_SYSCTL is defined. Apply this logic
to both the configure.ac and meson.build file.

[Thanks go to Renato Botelho <garga@FreeBSD.org> for testing this patch
on FreeBSD.]

Tested-by: Renato Botelho <garga@FreeBSD.org>
Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>
---
 configure.ac | 61 ++++++++++++++++++++++++++++++----------------------
 meson.build  | 10 +++++----
 2 files changed, 41 insertions(+), 30 deletions(-)

diff --git a/configure.ac b/configure.ac
index f6caab919a..bf710ac91a 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1067,32 +1067,6 @@ AC_CHECK_LIB([iconv], [locale_charset],
                      [CHARSET_LIB=-lcharset])])
 GIT_CONF_SUBST([CHARSET_LIB])
 
-#
-# Define HAVE_SYSINFO=YesPlease if sysinfo is available.
-#
-AC_DEFUN([HAVE_SYSINFO_SRC], [
-AC_LANG_PROGRAM([[
-#include <stdint.h>
-#include <sys/sysinfo.h>
-]], [[
-struct sysinfo si;
-uint64_t t = 0;
-if (!sysinfo(&si)) {
-	t = si.totalram;
-	if (si.mem_unit > 1)
-		t *= (uint64_t)si.mem_unit;
-}
-return t;
-]])])
-
-AC_MSG_CHECKING([for sysinfo])
-AC_COMPILE_IFELSE([HAVE_SYSINFO_SRC],
-	[AC_MSG_RESULT([yes])
-	HAVE_SYSINFO=YesPlease],
-	[AC_MSG_RESULT([no])
-	HAVE_SYSINFO=])
-GIT_CONF_SUBST([HAVE_SYSINFO])
-
 #
 # Define HAVE_CLOCK_GETTIME=YesPlease if clock_gettime is available.
 GIT_CHECK_FUNC(clock_gettime,
@@ -1221,6 +1195,41 @@ AC_COMPILE_IFELSE([BSD_SYSCTL_SRC],
 	HAVE_BSD_SYSCTL=])
 GIT_CONF_SUBST([HAVE_BSD_SYSCTL])
 
+#
+# Define HAVE_SYSINFO=YesPlease if sysinfo is available.
+#
+
+HAVE_SYSINFO=
+# on a *BSD system, sysctl() takes precedence over the
+# sysinfo() compatibility library (if installed).
+
+if test -z "$HAVE_BSD_SYSCTL"; then
+
+  AC_DEFUN([HAVE_SYSINFO_SRC], [
+  AC_LANG_PROGRAM([[
+  #include <stdint.h>
+  #include <sys/sysinfo.h>
+  ]], [[
+  struct sysinfo si;
+  uint64_t t = 0;
+  if (!sysinfo(&si)) {
+	t = si.totalram;
+	if (si.mem_unit > 1)
+		t *= (uint64_t)si.mem_unit;
+  }
+  return t;
+  ]])])
+
+  AC_MSG_CHECKING([for sysinfo])
+  AC_COMPILE_IFELSE([HAVE_SYSINFO_SRC],
+	[AC_MSG_RESULT([yes])
+	HAVE_SYSINFO=YesPlease],
+	[AC_MSG_RESULT([no])
+	HAVE_SYSINFO=])
+  GIT_CONF_SUBST([HAVE_SYSINFO])
+
+fi
+
 ## Other checks.
 # Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
 # Enable it on Windows.  By default, symrefs are still used.
diff --git a/meson.build b/meson.build
index 7fea4a34d6..355cad730c 100644
--- a/meson.build
+++ b/meson.build
@@ -1331,10 +1331,6 @@ if host_machine.system() != 'windows'
   endif
 endif
 
-if compiler.has_member('struct sysinfo', 'totalram', prefix: '#include <sys/sysinfo.h>')
-  libgit_c_args += '-DHAVE_SYSINFO'
-endif
-
 if compiler.has_member('struct stat', 'st_mtimespec.tv_nsec', prefix: '#include <sys/stat.h>')
   libgit_c_args += '-DUSE_ST_TIMESPEC'
 elif not compiler.has_member('struct stat', 'st_mtim.tv_nsec', prefix: '#include <sys/stat.h>')
@@ -1449,6 +1445,12 @@ if compiler.has_header('sys/sysctl.h')
   endif
 endif
 
+if not has_bsd_sysctl
+  if compiler.has_member('struct sysinfo', 'totalram', prefix: '#include <sys/sysinfo.h>')
+    libgit_c_args += '-DHAVE_SYSINFO'
+  endif
+endif
+
 if not meson.is_cross_build() and compiler.run('''
   #include <stdio.h>
 
-- 
2.50.0

Re: [PATCH] build: fix FreeBSD build when sysinfo compat library installed

[Eric Sunshine]

On Fri, Jul 4, 2025 at 6:26 PM Ramsay Jones <ramsay@ramsayjones.plus.com> wrote:
> Commit 50dec7c566 ("config.mak.uname: add sysinfo() configuration for
> cygwin", 2025-04-17) and later commit 187ce0222f ("configure.ac: upgrade
> to a compilation check for sysinfo", 2025-05-19) added a 'sysinfo()'
> check to the autoconf build.
>
> The FreeBSD system has an optional sysinfo compatibility library, used
> to assist in porting software, which causes the build to fail when it
> is installed. The reason for the failure is the lack of '-lsysinfo'
> during the linking step.
>
> Several solutions were considered:
>
>   - add an 'linking' check to configure.ac in order to determine the

s/an/a/

(not worth a reroll)

>     need to link a separate library (-lsysinfo). (This would require
>     a similar change to meson.build).
>
>   - change the order of the preprocessor conditionals in the total_ram()
>     function in 'builtin/gc.c', so that the *BSD sysctl() function
>     (in the HAVE_BSD_SYSCTL block) takes priority over the sysinfo()
>     function (in the HAVE_SYSINFO block).
>
>   - suppress the setting of HAVE_SYSINFO when HAVE_BSD_SYSCTL has been
>     defined (in both configure.ac and meson.build).
>
> The first solution above, while simple, adds unnecessary code (the
> sysinfo compat function is likely implemented using sysctl() anyway)
> when git is happy to use sysctl() on *BSD systems.
>
> The second solution would only be required by the autoconf and meson
> build systems, the Makefile already sets the build variables to the
> required values (since they are not 'auto-detected').
>
> Here we opt for the final solution above, since it only requires that
> we prioritise the 'auto-detected' build variables in the autoconf and
> meson builds.

The final solution is almost certainly good enough (and is definitely
simple), although the second solution has the benefit that it "fixes"
the problem once and for all even if someone defines both
HAVE_BSD_SYSCTL and HAVE_SYSINFO (say, in config.mak), assuming I'm
understanding correctly.

> In order to fix the FreeBSD build, move the sysinfo() check after the
> determination of the HAVE_BSD_SYSCTL build variable, suppressing the
> setting of HAVE_SYSINFO if HAVE_BSD_SYSCTL is defined. Apply this logic
> to both the configure.ac and meson.build file.

Nicely described. I wasn't really following along with the discussion,
but this commit message summarizes the situation well, so I can
understand the reason for the change and (I hope) the implications.

> Tested-by: Renato Botelho <garga@FreeBSD.org>
> Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com>

Re: [PATCH] build: fix FreeBSD build when sysinfo compat library installed

[Junio C Hamano]

Eric Sunshine <sunshine@sunshineco.com> writes:

>>     need to link a separate library (-lsysinfo). (This would require
>>     a similar change to meson.build).
>>
>>   - change the order of the preprocessor conditionals in the total_ram()
>>     function in 'builtin/gc.c', so that the *BSD sysctl() function
>>     (in the HAVE_BSD_SYSCTL block) takes priority over the sysinfo()
>>     function (in the HAVE_SYSINFO block).
>>
>>   - suppress the setting of HAVE_SYSINFO when HAVE_BSD_SYSCTL has been
>>     defined (in both configure.ac and meson.build).
>> ...
>> The second solution would only be required by the autoconf and meson
>> build systems, the Makefile already sets the build variables to the
>> required values (since they are not 'auto-detected').
> ...
> The final solution is almost certainly good enough (and is definitely
> simple), although the second solution has the benefit that it "fixes"
> the problem once and for all even if someone defines both
> HAVE_BSD_SYSCTL and HAVE_SYSINFO (say, in config.mak), assuming I'm
> understanding correctly.

Yeah, I think I agree with this assessment.

>> In order to fix the FreeBSD build, move the sysinfo() check after the
>> determination of the HAVE_BSD_SYSCTL build variable, suppressing the
>> setting of HAVE_SYSINFO if HAVE_BSD_SYSCTL is defined. Apply this logic
>> to both the configure.ac and meson.build file.
>
> Nicely described. I wasn't really following along with the discussion,
> but this commit message summarizes the situation well, so I can
> understand the reason for the change and (I hope) the implications.

Agreed.  Thanks, all.

Re: [PATCH] build: fix FreeBSD build when sysinfo compat library installed

[Ramsay Jones]

On 07/07/2025 16:40, Junio C Hamano wrote:
> Eric Sunshine <sunshine@sunshineco.com> writes:
> 
>>>     need to link a separate library (-lsysinfo). (This would require
>>>     a similar change to meson.build).
>>>
>>>   - change the order of the preprocessor conditionals in the total_ram()
>>>     function in 'builtin/gc.c', so that the *BSD sysctl() function
>>>     (in the HAVE_BSD_SYSCTL block) takes priority over the sysinfo()
>>>     function (in the HAVE_SYSINFO block).
>>>
>>>   - suppress the setting of HAVE_SYSINFO when HAVE_BSD_SYSCTL has been
>>>     defined (in both configure.ac and meson.build).
>>> ...
>>> The second solution would only be required by the autoconf and meson
>>> build systems, the Makefile already sets the build variables to the
>>> required values (since they are not 'auto-detected').
>> ...
>> The final solution is almost certainly good enough (and is definitely
>> simple), although the second solution has the benefit that it "fixes"
>> the problem once and for all even if someone defines both
>> HAVE_BSD_SYSCTL and HAVE_SYSINFO (say, in config.mak), assuming I'm
>> understanding correctly.
> 
> Yeah, I think I agree with this assessment.

[Sorry for the late reply - real life keeps getting in the way!]

Yep, I thought about including this fix *in addition to* the solution
implemented in this patch, but decided that the chances that anyone would
set both in a Makefile build was practically zero. (famous last words ;) ).

Of course, practically zero is not zero, so we could do this in a
follow-up patch if we wanted to take a more conservative approach.
(Carlos has a series in progress which would conflict with such a
patch - but the conflict resolution would be simple).

>>> In order to fix the FreeBSD build, move the sysinfo() check after the
>>> determination of the HAVE_BSD_SYSCTL build variable, suppressing the
>>> setting of HAVE_SYSINFO if HAVE_BSD_SYSCTL is defined. Apply this logic
>>> to both the configure.ac and meson.build file.
>>
>> Nicely described. I wasn't really following along with the discussion,
>> but this commit message summarizes the situation well, so I can
>> understand the reason for the change and (I hope) the implications.
> 
> Agreed.  Thanks, all.

Thanks!

Let me know if you would like that follow-up patch.

ATB,
Ramsay Jones

Re: [PATCH] build: fix FreeBSD build when sysinfo compat library installed

[Ramsay Jones]

On 07/07/2025 17:51, Ramsay Jones wrote:
> 
> 
> On 07/07/2025 16:40, Junio C Hamano wrote:
>> Eric Sunshine <sunshine@sunshineco.com> writes:
>>
>>>>     need to link a separate library (-lsysinfo). (This would require
>>>>     a similar change to meson.build).
>>>>
>>>>   - change the order of the preprocessor conditionals in the total_ram()
>>>>     function in 'builtin/gc.c', so that the *BSD sysctl() function
>>>>     (in the HAVE_BSD_SYSCTL block) takes priority over the sysinfo()
>>>>     function (in the HAVE_SYSINFO block).
>>>>
>>>>   - suppress the setting of HAVE_SYSINFO when HAVE_BSD_SYSCTL has been
>>>>     defined (in both configure.ac and meson.build).
>>>> ...
>>>> The second solution would only be required by the autoconf and meson
>>>> build systems, the Makefile already sets the build variables to the
>>>> required values (since they are not 'auto-detected').
>>> ...
>>> The final solution is almost certainly good enough (and is definitely
>>> simple), although the second solution has the benefit that it "fixes"
>>> the problem once and for all even if someone defines both
>>> HAVE_BSD_SYSCTL and HAVE_SYSINFO (say, in config.mak), assuming I'm
>>> understanding correctly.
>>
>> Yeah, I think I agree with this assessment.
> 
> [Sorry for the late reply - real life keeps getting in the way!]
> 
> Yep, I thought about including this fix *in addition to* the solution
> implemented in this patch, but decided that the chances that anyone would
> set both in a Makefile build was practically zero. (famous last words ;) ).
> 
> Of course, practically zero is not zero, so we could do this in a
> follow-up patch if we wanted to take a more conservative approach.
> (Carlos has a series in progress which would conflict with such a

Sigh, sorry, Carlo.

ATB,
Ramsay Jones

Re: [PATCH] build: fix FreeBSD build when sysinfo compat library installed

[Junio C Hamano]

Ramsay Jones <ramsay@ramsayjones.plus.com> writes:

> Of course, practically zero is not zero, so we could do this in a
> follow-up patch if we wanted to take a more conservative approach.
> (Carlos has a series in progress which would conflict with such a
> patch - but the conflict resolution would be simple).
> ...
> Let me know if you would like that follow-up patch.

Nah, I think good enough is good enough.  Not worth spending more
braincycles on it.  Unless you absolutely do not have anything
better to do, that is ;-)

If somebody really finds the "practically zero" solution disturbing,
they can do a follow-up after the dust settles, of course.