[BUG] `WITH_LIBCURL` is a dead build flag, never defined in any current build system

[kaihere14]

Summary

src/ccextractor.c (start_ccx()) contains a curl initialization block guarded by #ifdef WITH_LIBCURL:

#ifdef WITH_LIBCURL
	curl_global_init(CURL_GLOBAL_ALL);
	curl = curl_easy_init();
	if (!curl)
	{
		curl_global_cleanup();
		fatal(EXIT_NOT_CLASSIFIED, "Unable to init curl.");
	}
#endif

I investigated whether WITH_LIBCURL is actually defined by any current build path, and found that it isn't, anywhere. This looks like leftover code from a feature that was deliberately disabled almost 9 years ago and never revived.

Investigation

1. WITH_LIBCURL is never defined by any build system

Checked every build path in the repo: src/CMakeLists.txt (and other CMakeLists.txt files), linux/configure.ac, mac/configure.ac, linux/Makefile.am, mac/Makefile.am, windows/ccextractor.vcxproj[.filters], linux/build, all Dockerfiles, and all GitHub Actions workflows. None of them define or pass -DWITH_LIBCURL.

The macro only appears in C source under #ifdef guards (src/ccextractor.c, src/ccextractor.h, src/lib_ccx/ccx_encoders_common.c, src/lib_ccx/ccx_common_option.h, src/lib_ccx/lib_ccx.h, src/lib_ccx/params.c, src/lib_ccx/ccx_common_option.c, src/lib_ccx/ccx_encoders_curl.c) and as a comment in src/rust/src/parser.rs.

2. Near-misses that don't actually wire it up

• Windows (.vcxproj): compiles ccx_encoders_curl.c and links libcurl.lib, but never adds WITH_LIBCURL to PreprocessorDefinitions. Since the entire file is wrapped in #ifdef WITH_LIBCURL, it compiles to an empty translation unit, so MSVC links a curl import lib that's never used.
• linux/Makefile.am / mac/Makefile.am: list ccx_encoders_curl.c as a source unconditionally, but configure.ac never defines the macro, same dead-file situation.
• Docker / CI: docker/Dockerfile and several .github/workflows/*.yml install libcurl4-gnutls-dev as an apt dependency, but the build step is plain ./configure && make, no --with-curl flag exists, no -DWITH_LIBCURL is ever passed. This is a vestigial dependency install with no effect on the resulting binary.
• linux/build (the manual build script, still run today by .github/workflows/build_linux_systemlibs.yml): has zero curl flags, no -DWITH_LIBCURL, no -lcurl.

3. Git history confirms this was intentional, not an oversight

2016-09-26 17dd669 Initial libcurl integration work, linux only
2016-09-28 67a3ed3 Merging curl (introduced the block above)
2016-09-28 8729ae1 Disabling CURL in Windows
2016-09-28 56719e7 Libcurl
2016-12-14 9996836 Removed LIBCURL in linux build script, since that stuff is not complete

Commit 99968362 diff (linux/build, the only build script that existed at the time):

-BLD_FLAGS="...  -DENABLE_OCR -DWITH_LIBCURL"
+BLD_FLAGS="...  -DENABLE_OCR"
-BLD_LINKER="-lm -zmuldefs -l tesseract -l lept -lcurl"
+BLD_LINKER="-lm -zmuldefs -l tesseract -l lept"

The original author pulled the flag about 2.5 months after adding it, explicitly calling the feature incomplete. It was never reintroduced across the subsequent switch to autotools, CMake, or the MSVC vcxproj, confirmed by searching WITH_LIBCURL across full commit history.

4. It's not broken, just unreachable

If WITH_LIBCURL were defined and -lcurl linked, this code would build fine. curl/CURLcode res are declared in src/ccextractor.h:22-25 under the same guard, and ccx_encoders_curl.c references them consistently. It's a self-consistent feature that simply nothing switches on.

5. Rust-side wrinkle

src/rust/lib_ccxr/Cargo.toml has a Cargo feature with_libcurl in the default feature list, a completely separate flag namespace from the C macro. It only gates passing through curlposturl config (parser.rs:1595,1668) with no actual networking, since the real curl work in ccx_encoders_curl.c is never compiled in. This means -curlposturl currently parses successfully but does nothing functional.

Proposed options

I'd suggest one of the following, and I'm happy to take either on:

• Option A, remove the dead code (recommended, smaller/safer PR): strip the never-compiled #ifdef WITH_LIBCURL blocks, ccx_encoders_curl.c, the unused libcurl.lib link in the vcxproj, the vestigial libcurl4-gnutls-dev installs in Docker/CI, and the Rust-side with_libcurl default feature (or the -curlposturl CLI surface, if that's also intended to go). This reduces dead weight in the codebase and CI without touching any functionality anyone currently relies on, since none of it is reachable today.
• Option B, revive the feature: wire WITH_LIBCURL back into CMake/autotools/vcxproj as an actual opt-in build option, so -curlposturl and any other curl-dependent functionality become real again. Bigger scope, and probably only worth doing if there's active interest in this feature returning.

I lean toward Option A as the safer first step, with Option B left as a possible follow-up if maintainers want the feature back.

Would like to be assigned

If this is something the project wants addressed, I'd like to be assigned and submit a PR for it (Option A, unless a maintainer prefers Option B).

[kaihere14]

Hey @cfsmp3 , could you take a look at this when you get a chance and let me know if this is worth pursuing, and if so whether Option A or B makes more sense? Happy to be assigned and take it on either way.