GCC 12.2 Support

[jackbow]

Since the windows github action runner upgraded gcc to 12.2 last week, my go builds have been failing with the errors below coming from go-fitz. I imagine the windows mupdflib*.a files need to be recompiled using gcc 12.2 to fix it, but I haven't had success with it.

I followed the mupdf windows build instructions & built libmupdf in visual studio, but wasn't able to find any resulting .a files. I tried running make from mingw, which worked aside from not being able to find a build/release/th file in order to generate libmupdfthird.a

If anyone has advice on how to build libmupdf.a and libmupdfthird.a on windows, or more generally about what's going wrong, that'd be hugely appreciated.

Thanks for writing and supporting this library! It's been super useful for us.

C:\hostedtoolcache\windows\go\1.20.8\x64\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/runneradmin/go/pkg/mod/github.com/gen2brain/go-fitz@v1.23.1/libs/libmupdf_windows_amd64.a(buffer.o):buffer.c:(.text$fz_new_buffer+0x47): undefined reference to `_setjmp'
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/runneradmin/go/pkg/mod/github.com/gen2brain/go-fitz@v1.23.1/libs/libmupdf_windows_amd64.a(buffer.o):buffer.c:(.text$fz_new_buffer_from_data+0x28): undefined reference to `_setjmp'
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/runneradmin/go/pkg/mod/github.com/gen2brain/go-fitz@v1.23.1/libs/libmupdf_windows_amd64.a(buffer.o):buffer.c:(.text$fz_new_buffer_from_base64+0xf8): undefined reference to `_setjmp'
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/runneradmin/go/pkg/mod/github.com/gen2brain/go-fitz@v1.23.1/libs/libmupdf_windows_amd64.a(colorspace.o):colorspace.c:(.text$fz_cached_color_convert+0x9c): undefined reference to `_setjmp'
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/runneradmin/go/pkg/mod/github.com/gen2brain/go-fitz@v1.23.1/libs/libmupdf_windows_amd64.a(colorspace.o):colorspace.c:(.text$fz_new_colorspace+0x68): undefined reference to `_setjmp'
C:/ProgramData/Chocolatey/lib/mingw/tools/install/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:/Users/runneradmin/go/pkg/mod/github.com/gen2brain/go-fitz@v1.23.1/libs/libmupdf_windows_amd64.a(colorspace.o):colorspace.c:(.text$fz_new_icc_colorspace+0x62): more undefined references to `_setjmp' follow
collect2.exe: error: ld returned 1 exit status

[epssy]

Yup, looks like it needs a recompile.

@gen2brain left detailed instructions here which work but satisfying all of the dependencies on Windows is a royal pain. I got as far as freetype before giving up for the day. If anyone else has a go just use Linux for this step instead.

> set OPTS="HAVE_X11=no HAVE_GLFW=no HAVE_GLUT=no WANT_OPENSSL=no WANT_CURL=no HAVE_MUJS=yes HAVE_JSCORE=no HAVE_V8=no"
> set CROSSCOMPILE=yes
> set PKG_CONFIG_LIBDIR="C:\Users\user\Code\msys2\ucrt64\lib"
> set CROSS="i686-w64-mingw32-"
PS C:\Users\user\Code\mupdf> make libs OS=mingw64-cross
File not found - *.[ch]
...
make: *** No rule to make target 'build/mingw64-cross/release/thirdparty/freetype/src/base/ftbase.o', needed by 'build/mingw64-cross/release/libmupdf-third.a'.  Stop.

As a side note, there's discussions in several other projects, like this one, about no longer needing libmupdf-third.a when static compiling.

[gen2brain]

@epssy If you don't use bundled 3rd party dependencies and use system dependencies then you need them installed on the system. That is all optional, and all cases are handled in go-fitz with tags. Not sure what that discussion is about, it all depends on how someone compiles mupdf.

[epssy]

@gen2brain the specific issue is that building a go project that includes go-fitz with known good build tags will fault during the linking phase with the error @jackbow reported above. This appears to be caused by a mismatch between GCC 12.2 / UCRT and the version of GCC / CRT that was used to build the bundled libmupdf.a and libmupdf-third.a. Apparently recompiling using the latest distributions of the build chain should cause build tags to work again when building on Windows.

My comment was just about secondary issues encountered when trying to compile these two files locally and can be ignored.

[gen2brain]

@epssy Ok, I understand now, sorry it was not clear to me at first. Anyway, there will not be a special Windows-only fix, when the library is updated I will recompile everything for all platforms. Users can just use the external library until this is fixed.

[rntrp]

Before the new lib version gets released, I tried to downgrade the MinGW version from 12.2 to 11.2 as suggested here: go-gst/go-gst#48

Unfortunately my build still fails with exact same error: https://github.com/rntrp/go-fitz-formpost/actions/runs/6896139531/job/18761622016

I guess I just wait for the recompiled library unless somebody finds a proper workaround.

[gen2brain]

This is actually not related just to the GCC version, but with the new ucrt vs the old msvcrt libc. The proper solution would be to build for both so one is the default, and the other is available via some build tag. But I will have to bootstrap my toolchain with ucrt.

[epssy]

I had similar issues compiling under the old and new CRTs when I tried last month.

In the end I just started building it under Linux and that's worked nicely since. 🚀

[rntrp]

@epssy Are you using GitHub Actions for building your application? I'm currently struggling with setting up my own Actions pipeline for Windows. It would be nice if you could provide an example.

[gen2brain]

This should be fixed now, though I still cannot verify with actions, the job timeouts, but I am able to build binary with ucrt toolchain.

[rntrp]

@gen2brain thank you very much indeed, for now my build is working as expected.

Regarding failed tests: I've just set up an almost identical test workflow for my project which doesn't throw any timeouts. From what I can see, the used GitHub Actions are a bit dated. Hence I would suggest updating both actions/setup-go@v4 as well as actions/checkout@v4 and then try again.