Created attachment 27244 [details]
ghostscript-10.06.0_build.log

On Ubuntu 24.04.3 LTS the build runs to completion with all the same shared libraries you would be relying on (given the "rm -r ./cups/libs ./brotli ./freetype ./jbig2dec ./jpeg ./lcms2mt ./leptonica ./libpng ./openjpeg ./tesseract ./tiff ./zlib" line from your build log).

I can't see anything that's changed with the tesseract integration since 10.05.0 was released.

I'm not sure how to proceed.

(In reply to Chris Liddell (chrisl) from comment #2)
> On Ubuntu 24.04.3 LTS the build runs to completion with all the same shared
> libraries you would be relying on (given the "rm -r ./cups/libs ./brotli
> ./freetype ./jbig2dec ./jpeg ./lcms2mt ./leptonica ./libpng ./openjpeg
> ./tesseract ./tiff ./zlib" line from your build log).
> 
> I can't see anything that's changed with the tesseract integration since
> 10.05.0 was released.
> 
> I'm not sure how to proceed.

Thanks for looking into it, after your message I also had a deeper look and found 

https://github.com/ArtifexSoftware/ghostpdl/commit/ad18a3036bda27fcd74e08050834d7db4aafe7e2

as the offending commit. And reverting the line in ocr.mak

diff -Naur ghostpdl-ghostpdl-10.06.0/base/ocr.mak ghostpdl-ghostpdl-10.06.0.new/base/ocr.mak
--- ghostpdl-ghostpdl-10.06.0/base/ocr.mak	2025-09-09 11:34:47.000000000 +0200
+++ ghostpdl-ghostpdl-10.06.0.new/base/ocr.mak	2025-09-22 16:33:56.222499979 +0200
@@ -20,7 +20,7 @@
 
 # Define the name of this makefile.
 LIBOCR_MAK=$(GLSRC)ocr.mak $(TOP_MAKEFILES)
-OCRCXX = $(CXX) $(TESSINCLUDES) $(TESSCXXFLAGS) $(CCXXFLAGS) -DTESSERACT_IMAGEDATA_AS_PIX -DTESSERACT_DISABLE_DEBUG_FONTS -DGRAPHICS_DISABLED -UCLUSTER
+OCRCXX = $(CXX) $(TESSINCLUDES) $(TESSCXXFLAGS) $(CCFLAGS) -DTESSERACT_IMAGEDATA_AS_PIX -DTESSERACT_DISABLE_DEBUG_FONTS -DGRAPHICS_DISABLED -UCLUSTER
 
 # Tesseract veneer.
 $(GLGEN)tessocr.$(OBJ) : $(GLSRC)tessocr.cpp $(GLSRC)tessocr.h $(LIBOCR_MAK) \

allows my build to succeed.

Though I'm not sure how to fix this properly, for other flags we use the *AUX option to specify/pass our own like CPPFLAGSAUX for example but there doesn't seem to be a similiar one for CCXXFLAGSAUX. We set those for cross-compiliation https://gitlab.exherbo.org/exherbo/arbor/-/blob/master/packages/app-text/ghostscript/ghostscript-10.05.1.exheres-0?ref_type=heads#L115-L118 the relevant bug back then was https://bugs.ghostscript.com/show_bug.cgi?id=701689.

Unfortunately, that's just left me even more confused.

That commit replaces the variable CCFLAGS with the variable CCXXFLAGS, which should contain all the same options as CCFLAGS _except_ "-Wstrict-prototypes" and "-Wmissing-prototypes" neither of which are relevant for C++.

So any options that were being pass through the configure script and included in CCFLAGS should also end up in CCXXFLAGS.


The comment about the *AUX options confuses me even further, since those are used when building the interim tools (genconf, genarch, and mkromfs) which are called during the build, in the build environment (not the host), and none of them use C++ nor should they be linking to tesseract.

(Note that I'm not discounting that I may have messed something up, just trying to get my head around what's happening)

(In reply to Chris Liddell (chrisl) from comment #4)
> Unfortunately, that's just left me even more confused.
> 
> That commit replaces the variable CCFLAGS with the variable CCXXFLAGS, which
> should contain all the same options as CCFLAGS _except_
> "-Wstrict-prototypes" and "-Wmissing-prototypes" neither of which are
> relevant for C++.
> 
> So any options that were being pass through the configure script and
> included in CCFLAGS should also end up in CCXXFLAGS.
> 
> 
> The comment about the *AUX options confuses me even further, since those are
> used when building the interim tools (genconf, genarch, and mkromfs) which
> are called during the build, in the build environment (not the host), and
> none of them use C++ nor should they be linking to tesseract.

That was my mistake then of course, I thought things could be related due to the fact that I have no real clue where to look for. All I have for now is that the "patch" altering that line to what is was before allows gs to build. I tried to see if I can find something diffing a failed and a working build log but couldn't spot anything obvious apart from having the addition three warning lines on a working build

cc1plus: warning: command-line option '-Wstrict-prototypes' is valid for C/ObjC but not for C++
cc1plus: warning: command-line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++
cc1plus: warning: '-Werror=' argument '-Werror=declaration-after-statement' is not valid for C++

which is what you mentioned before. I'll try to revert the whole commit tomorrow and see if it fails then as well or if there's something else I can find out, as you already saw I'm kinda lost here as I'm not that deep into build stuff sorry for that and any false conclusions I might do. For now I'm attaching a build log from a working build.

Created attachment 27251 [details]
ghostscript-10.06.0-build-log-of-working-with-patch.log

Port maintainer on FreeBSD here: Committed 10.06.0 yesterday and received the very same issue from a fellow committer. I will try the one-off patch in the Makefile.

The reverse patch works for me: https://reviews.freebsd.org/D52722

Created attachment 27264 [details]
ghostscript-gpl-10.06.0-tesseract-fPIC.patch

Gentoo ships with a different approach, the attached patch is adding passing -fPIC and can be found at https://gitweb.gentoo.org/repo/gentoo.git/tree/app-text/ghostscript-gpl/files/ghostscript-gpl-10.06.0-tesseract-fPIC.patch