* [PATCH v2] config.mak.uname: update settings for FreeBSD
@ 2025-06-12 4:36 Brad Smith
0 siblings, 0 replies; 5+ messages in thread
From: Brad Smith @ 2025-06-12 4:36 UTC (permalink / raw)
To: git
From bdeb596fa6a99c4059df52bbdaed08268100c43e Mon Sep 17 00:00:00 2001
From: Brad Smith <brad@comstyle•com>
Date: Mon, 9 Jun 2025 14:27:39 -0400
Subject: [PATCH] config.mak.uname: update settings for FreeBSD
FreeBSD 6.0 has memmem().
With making 6.0 the minimum version drop bits for supporting
FreeBSD 4.x.
Signed-off-by: Brad Smith <brad@comstyle•com>
---
config.mak.uname | 6 ------
1 file changed, 6 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index b1c5c4d5e8..da592eeaa0 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -302,16 +302,10 @@ ifeq ($(uname_S),FreeBSD)
ifeq ($(firstword $(subst -, ,$(uname_R))),10.1)
OLD_ICONV = YesPlease
endif
- NO_MEMMEM = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
USE_ST_TIMESPEC = YesPlease
- ifeq ($(shell expr "$(uname_R)" : '4\.'),2)
- PTHREAD_LIBS = -pthread
- NO_UINTMAX_T = YesPlease
- NO_STRTOUMAX = YesPlease
- endif
PYTHON_PATH = /usr/local/bin/python
PERL_PATH = /usr/local/bin/perl
HAVE_PATHS_H = YesPlease
--
2.49.0
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH v2] config.mak.uname: update settings for FreeBSD
@ 2025-06-12 13:52 Carlo Arenas
2025-06-12 16:48 ` brian m. carlson
2025-06-12 16:52 ` Junio C Hamano
0 siblings, 2 replies; 5+ messages in thread
From: Carlo Arenas @ 2025-06-12 13:52 UTC (permalink / raw)
To: Brad Smith; +Cc: git
On Thu, Jun 12, 2025 at 12:36:46AM -0800, Brad Smith wrote:
>
> FreeBSD 6.0 has memmem().
but AFAIK it was buggy, uncompatible with the "standard" and
didn't perform that well, at least until FreeBSD 12.
assuming that the system version is indeed faster than the
one provided with git (which should be true but worth testing)
then it might be better to only enable this for later versions?
> With making 6.0 the minimum version drop bits for supporting
> FreeBSD 4.x.
FreeBSD 4.x is no longer supported and wouldn't even build a
current git, since it predates C99 and is missing POSIX
compatibility with what we require (ex: no statvfs)
Carlo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] config.mak.uname: update settings for FreeBSD
2025-06-12 13:52 Carlo Arenas
@ 2025-06-12 16:48 ` brian m. carlson
2025-06-12 21:31 ` Carlo Marcelo Arenas Belón
2025-06-12 16:52 ` Junio C Hamano
1 sibling, 1 reply; 5+ messages in thread
From: brian m. carlson @ 2025-06-12 16:48 UTC (permalink / raw)
To: Carlo Arenas; +Cc: Brad Smith, git
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
On 2025-06-12 at 13:52:03, Carlo Arenas wrote:
> On Thu, Jun 12, 2025 at 12:36:46AM -0800, Brad Smith wrote:
> >
> > FreeBSD 6.0 has memmem().
>
> but AFAIK it was buggy, uncompatible with the "standard" and
> didn't perform that well, at least until FreeBSD 12.
>
> assuming that the system version is indeed faster than the
> one provided with git (which should be true but worth testing)
> then it might be better to only enable this for later versions?
FreeBSD 11.4 (the last version of FreeBSD 11) went end of life in
September 2021, so nobody should be using it since it hasn't had
security support since then. And it's even been functional (but slow)
since FreeBSD 11.0, and 10.4 went EOL in 2018. So users shouldn't
actually be experiencing any actual functionality problems since then.
I don't think it's a big deal for people who want to use an obsolete OS
(which, to be clear, I'm not encouraging) to tweak the Makefile knobs a
bit.
> > With making 6.0 the minimum version drop bits for supporting
> > FreeBSD 4.x.
>
> FreeBSD 4.x is no longer supported and wouldn't even build a
> current git, since it predates C99 and is missing POSIX
> compatibility with what we require (ex: no statvfs)
I definitely think getting rid of FreeBSD 4 support is fine. It doesn't
even support AMD64, so as a practical matter it wouldn't be useful on
any sort of modern hardware.
--
brian m. carlson (they/them)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] config.mak.uname: update settings for FreeBSD
2025-06-12 16:48 ` brian m. carlson
@ 2025-06-12 21:31 ` Carlo Marcelo Arenas Belón
0 siblings, 0 replies; 5+ messages in thread
From: Carlo Marcelo Arenas Belón @ 2025-06-12 21:31 UTC (permalink / raw)
To: brian m. carlson, Brad Smith, git
On Thu, Jun 12, 2025 at 04:48:49PM -0800, brian m. carlson wrote:
> On 2025-06-12 at 13:52:03, Carlo Arenas wrote:
> > On Thu, Jun 12, 2025 at 12:36:46AM -0800, Brad Smith wrote:
> > >
> > > FreeBSD 6.0 has memmem().
> >
> > but AFAIK it was buggy, uncompatible with the "standard" and
> > didn't perform that well, at least until FreeBSD 12.
> >
> > assuming that the system version is indeed faster than the
> > one provided with git (which should be true but worth testing)
> > then it might be better to only enable this for later versions?
>
> FreeBSD 11.4 (the last version of FreeBSD 11) went end of life in
> September 2021, so nobody should be using it since it hasn't had
> security support since then. And it's even been functional (but slow)
> since FreeBSD 11.0, and 10.4 went EOL in 2018. So users shouldn't
> actually be experiencing any actual functionality problems since then.
>
> I don't think it's a big deal for people who want to use an obsolete OS
> (which, to be clear, I'm not encouraging) to tweak the Makefile knobs a
> bit.
Note that my concern wasn't about having to tweak the Makefile, but with
the fact that the system provided function would behave differently, and
there was no attempt to see if by no longer using the git provided compat
code, there was actually a performance improvement.
It is true that in our codebase there are no calls to memmem() where the
needlelen (the fourth parameter) could be zero, and that would result in
some of those old versions returning NULL, but it would seem to be safer
to only use the system provided function when those issues are no longer
a concern.
Carlo
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH v2] config.mak.uname: update settings for FreeBSD
2025-06-12 13:52 Carlo Arenas
2025-06-12 16:48 ` brian m. carlson
@ 2025-06-12 16:52 ` Junio C Hamano
1 sibling, 0 replies; 5+ messages in thread
From: Junio C Hamano @ 2025-06-12 16:52 UTC (permalink / raw)
To: Carlo Arenas; +Cc: Brad Smith, git
Carlo Arenas <carenas@gmail•com> writes:
> On Thu, Jun 12, 2025 at 12:36:46AM -0800, Brad Smith wrote:
>>
>> FreeBSD 6.0 has memmem().
>
> but AFAIK it was buggy, uncompatible with the "standard" and
> didn't perform that well, at least until FreeBSD 12.
Declaring that we will not support anything older than 12, which was
from Dec 2018, feels a bit too harsh, so conditional to check if we
are at or above 12 is needed instead?
Documentation/technical/platform-support.adoc is probably a good
place to start a discussion.
* It spells out Minimum Requirements which includes C99 at the
minimum, which in turn disqualifies really ancient ones and ones
perhaps before FreeBSD 7 (which had GCC 4)?
* It also requires the platform has active security support. If I
trust https://www.freebsd.org/security/#sup page, it means
anything older than 13.4-RELEASE are EoL already.
* The document has a space at the end that is intended to list
contacts for ports on platforms, but currently it is not very
actively used. Should we extend it to include various flavours
of BSDs and other systems, and start listing the minimum
supported versions as well?
Stepping back a bit, do we already have some mechanism to say "hey
you seem to be on FreeBSD but you are at release N that is way older
than the minimum version X we support" and stop the build? If we
do, we should tell that mechanism about our decision in a patch like
this.
If we don't, I wonder if we want to have such a mechanism? I am
personally undecided. It would help those "casual" users and
builders who do not get their hands dirty at all (aka "I'll build
only from the official release tarballs") if we did so when they try
to build on something we know will not work well, especially if it
is kept up to date relative to what the platform-support document
lists. But at the same time, those who do not mind fixing and
extending to make it work on out-of-support systems will be
inconvenienced with one more roadblock to dismantle before
proceeding.
Thoughts?
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-06-12 21:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-12 4:36 [PATCH v2] config.mak.uname: update settings for FreeBSD Brad Smith
-- strict thread matches above, loose matches on Subject: below --
2025-06-12 13:52 Carlo Arenas
2025-06-12 16:48 ` brian m. carlson
2025-06-12 21:31 ` Carlo Marcelo Arenas Belón
2025-06-12 16:52 ` Junio C Hamano
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox