From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <sunshine@sunshineco.com>
Cc: Ramsay Jones <ramsay@ramsayjones.plus.com>,
GIT Mailing-list <git@vger.kernel.org>,
Patrick Steinhardt <ps@pks.im>,
Renato Botelho <garga@freebsd.org>,
Eli Schwartz <eschwartz@gentoo.org>
Subject: Re: [PATCH] build: fix FreeBSD build when sysinfo compat library installed
Date: Mon, 07 Jul 2025 08:40:27 -0700 [thread overview]
Message-ID: <xmqqzfdg3t78.fsf@gitster.g> (raw)
In-Reply-To: <CAPig+cTybBgkwFEsMVNNu2o1w9T5qnhau4chvGU2opEPJO78zg@mail.gmail.com> (Eric Sunshine's message of "Fri, 4 Jul 2025 19:49:53 -0400")
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.
next prev parent reply other threads:[~2025-07-07 15:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-04 22:23 [PATCH] build: fix FreeBSD build when sysinfo compat library installed Ramsay Jones
2025-07-04 23:49 ` Eric Sunshine
2025-07-07 15:40 ` Junio C Hamano [this message]
2025-07-07 16:51 ` Ramsay Jones
2025-07-07 16:58 ` Ramsay Jones
2025-07-07 17:12 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzfdg3t78.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=eschwartz@gentoo.org \
--cc=garga@freebsd.org \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--cc=ramsay@ramsayjones.plus.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.