Homebrew
gettext 1.0 build fails from source when json-c is present #6693
Replies: 5 comments 6 replies
-
|
I’m running into this issue as well. Is there a workaround we can use until the proposed solution is implemented? |
Beta Was this translation helpful? Give feedback.
-
|
So far my workaround is: I'm on older (Homebrew Tier-3) macOS due to hardware constraints, so everything is built from source. It took 20 minutes to confirm, but so far this seems to be working. An alternative might be |
Beta Was this translation helpful? Give feedback.
-
|
Well, my fix locally was to modify the formula to include json as a dependency with the correct paths - but I'm not sure that is the correct global fix (so I didn't turn that into a PR). So manually modifying the formula using Option A as above will work. You probably want to do that using the proper "brew edit" command and with a plan to git stash your changes, etc |
Beta Was this translation helpful? Give feedback.
-
|
I don't think the proposed fix is quite right; I think upstream should fix their configure output so that if libjson-c is detected and used, the compiler gets the right include path. Or Homebrew should disable unneeded tools from the build of gettext. FWIW, |
Beta Was this translation helpful? Give feedback.
-
|
I edited the formula after the upgrade failed, so the formula had already been updated. As for my fix vs some other option that could be done upstream - that's why I only raised an issue instead of pushing a Pull Request with an updated formula. There are probably at least three viable options for addressing this. The key thing from my perspective is that this is a basic dependency problem and not solely an issue on Tier 3 systems. Until there is a fix, I'm personally happy to modify the formula and run a custom personal tap to hold it (I've had to do the same for Boost and a couple of other formulae that need C++17 support for aligned_alloc memory calls). |
Beta Was this translation helpful? Give feedback.
-
|
Interesting. After the update failed |
Beta Was this translation helpful? Give feedback.
-
|
I ran into this issue as well. It seems like in addition to Option C: make a PR in From cdb1a5ffc4bfcf0f56ea7eb66bda88fb24c677cd Mon Sep 17 00:00:00 2001
From: Deyao Chen <chendeyao000@gmail.com>
Date: Thu, 19 Feb 2026 13:14:38 +0000
Subject: [PATCH] add --without-spit-c
---
gettext-tools/configure.ac | 14 +++++++++++++-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/gettext-tools/configure.ac b/gettext-tools/configure.ac
index 7fe2d28a4..b1924232e 100644
--- a/gettext-tools/configure.ac
+++ b/gettext-tools/configure.ac
@@ -563,7 +563,19 @@ fi
AC_MSG_RESULT([$gt_libcurl_found])
dnl Check in which form to install the 'spit' program.
-AM_CONDITIONAL([BUILD_SPIT_IN_C], [test -n "$LIBJSON_C" && test -n "$LIBCURL"])
+AC_ARG_WITH([spit-c],
+ [ --without-spit-c use the Python script spit.py instead of building a C executable],
+ [gt_build_spit_in_c=$withval],
+ [gt_build_spit_in_c=maybe])
+if test "$gt_build_spit_in_c" = maybe; then
+ dnl Auto-detect: use C if both libraries are available, otherwise use Python
+ if test -n "$LIBJSON_C" && test -n "$LIBCURL"; then
+ gt_build_spit_in_c=yes
+ else
+ gt_build_spit_in_c=no
+ fi
+fi
+AM_CONDITIONAL([BUILD_SPIT_IN_C], [test "$gt_build_spit_in_c" = yes])
dnl Check for Emacs and where to install .elc files.
dnl Sometimes Emacs is badly installed. Allow the user to work around it.
--
2.39.5 (Apple Git-154)
|
Beta Was this translation helpful? Give feedback.
-
|
Right. I think Homebrew need not ship spit-c, or upstream should allow it to be disabled, or upstream should at least generate correct include paths. Probably latter is best long-term, but I also don't see why I need spit-c from gettext ;) |
Beta Was this translation helpful? Give feedback.
-
|
So I just submitted the patch to upstream. I'll see how it goes |
Beta Was this translation helpful? Give feedback.
-
Actually this is not the reason why build fails. When make runs, the environment variable It was surprisingly difficult to debug, because even when you run |
Beta Was this translation helpful? Give feedback.
-
|
Ok so I got a reply from the Full email: https://lists.gnu.org/archive/html/bug-gettext/2026-02/msg00047.html |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Output of
brew configOutput of
brew doctorDescription of issue
Description
The gettext 1.0 formula fails to build from source when json-c is installed on the system, due to a missing dependency declaration and misconfigured include paths.
Steps to Reproduce
Expected Behavior
• Either: Build succeeds with the C version of spit (requires declaring json-c as a dependency)
• Or: Build succeeds with the Python fallback version of spit (requires disabling the C build)
Actual Behavior
Build fails with:
The root cause appears to be that gettext 1.0 introduced a new program spit (for querying LLMs) that has two build modes:
The relevant code in gettext's configure script:
The formula does not declare json-c as a dependency. The configure script's pkg-config check generates a malformed include path (-I///usr/local/include/json-c with triple slashes) which fails to locate the header.
This creates inconsistent behavior:
• Pre-built bottles were liikely built without json-c present, resulting in Python spit.py
• Building from source with json-c installed attempts a C build but fails
Impact
While discovered on a macOS 10.15 system, this likley affects all users building from source who have json-c installed, not just unsupported macOS versions:
• Users on supported macOS building from source
• Linux users
• CI/CD pipelines building from source
Proposed Solutions
Option A: Explicitly support the C version of spit (recommended for feature completeness)
Option B: Force Python version for consistency with bottles
Beta Was this translation helpful? Give feedback.
All reactions