Skip to content

fix: add -D_GNU_SOURCE to CFLAGS for strcasestr visibility on Linux#111

Merged
DeusData merged 1 commit intoDeusData:mainfrom
trollkotze:fix/add-gnu-source-for-strcasestr
Mar 23, 2026
Merged

fix: add -D_GNU_SOURCE to CFLAGS for strcasestr visibility on Linux#111
DeusData merged 1 commit intoDeusData:mainfrom
trollkotze:fix/add-gnu-source-for-strcasestr

Conversation

@trollkotze
Copy link

PR description generated by AI (Claude Opus 4.6), with some human commentary at the bottom.

Problem

Build fails on Linux (tested: Mint 21.2, glibc 2.35, gcc 11.4) with:

error: implicit declaration of function 'strcasestr' [-Werror=implicit-function-declaration]
in src/pipeline/pass_configlink.c

, where cbm_strcasestr maps to strcasestr on non-Windows.

Root cause

The build uses -std=c11 which defines STRICT_ANSI, suppressing GNU extensions. _DEFAULT_SOURCE is intended to re-enable them, but strcasestr is a GNU extension that requires _GNU_SOURCE on some glibc configurations.

Fix

Add -D_GNU_SOURCE to CFLAGS_COMMON in Makefile.cbm. This is safe on all platforms: it's a superset of _DEFAULT_SOURCE on glibc, a no-op on macOS/BSD, and recognized by musl. The Windows codepath is unaffected (uses its own cbm_strcasestr implementation).

Human commentary (by me)

Here some clariying conversation with my AI slave (Claude Opus 4.6) who came up with this fix:

Me:

And about that compile fix from earlier:
I changed the Makefile.cbm like so, to make it work for me:

diff --git a/Makefile.cbm b/Makefile.cbm
index 37e53ea..2bd843d 100644
--- a/Makefile.cbm
+++ b/Makefile.cbm
@@ -45,7 +45,7 @@ GCC_ONLY_FLAGS := -Wno-format-truncation -Wno-unused-result \
                   -Wno-stringop-truncation -Wno-alloc-size-larger-than
 endif
 
-CFLAGS_COMMON = -std=c11 -D_DEFAULT_SOURCE -Wall -Wextra -Werror \
+CFLAGS_COMMON = -std=c11 -D_DEFAULT_SOURCE -D_GNU_SOURCE -Wall -Wextra -Werror \
                 -Wno-unused-parameter -Wno-sign-compare \
                 $(GCC_ONLY_FLAGS) \
                 -Isrc -Ivendored -Ivendored/sqlite3 \ 

But will this work for everyone? Or how to modify it to not break existing working compiles on other systems? You mentioned it's likely because of my old glibc version (2.35). Is that sure? Is there a specific version number from which on this fix would not be needed anymore, or would be even detrimental?
Tell me how to modify the Makefile.cbm to cover the broadest range of affected systems that need the fix while leaving the config as it was for systems that don't.

AI slave (Opus 4.6):

Good question. Let me check the actual facts before giving advice.
_GNU_SOURCE is a superset of _DEFAULT_SOURCE. On glibc, _GNU_SOURCE implies _DEFAULT_SOURCE, _BSD_SOURCE, _SVID_SOURCE, _POSIX_C_SOURCE, and more. It has never been harmful on any glibc version — it only adds declarations, never removes them. It's also ignored on non-glibc systems (macOS, musl, BSDs) where it's simply an unknown macro.

The real question is: does adding _GNU_SOURCE break anything on macOS (Apple Clang) or musl-based systems?

  • macOS: Apple's headers don't check _GNU_SOURCE. It's a no-op. No effect.
  • musl libc: musl does recognize _GNU_SOURCE and exposes strcasestr when it's defined. So it actually helps there too.
  • FreeBSD/OpenBSD: They don't check _GNU_SOURCE either. strcasestr is available by default on BSDs.
  • Windows (MSVC/MinGW): The code already has a #ifdef _WIN32 branch with its own cbm_strcasestr implementation. _GNU_SOURCE is ignored.

As for glibc versions: strcasestr has been in glibc since forever (glibc 2.1). The issue isn't the glibc version — it's the interaction between -std=c11 (which sets STRICT_ANSI) and _DEFAULT_SOURCE. In theory _DEFAULT_SOURCE should override STRICT_ANSI for strcasestr on all glibc versions ≥ 2.19. But in practice, the glibc headers have had inconsistencies about which functions are gated on _GNU_SOURCE vs _DEFAULT_SOURCE. Your glibc 2.35 is not "old" — it's the current Ubuntu 22.04 / Mint 21.x version. This is a mainstream platform.

Bottom line: Adding -D_GNU_SOURCE is safe on every platform this project targets. It's what most C projects do (the Linux kernel, systemd, Git, SQLite's shell — they all define _GNU_SOURCE). Your diff is the correct fix as-is. No conditional logic needed.

@DeusData DeusData added the bug Something isn't working label Mar 22, 2026
@DeusData DeusData merged commit e4763a1 into DeusData:main Mar 23, 2026
@DeusData
Copy link
Owner

Merged to main. Thanks @trollkotze — clean one-liner fix for a real build failure on mainstream Linux (glibc + -std=c11). The thorough explanation in the PR body with the _GNU_SOURCE analysis across platforms was a nice touch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants