GCC 12.2 Support about go-fitz HOT 10 OPEN

@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.

from go-fitz.

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.

from go-fitz.

@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.

from go-fitz.

@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.

from go-fitz.

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.

from go-fitz.

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.

from go-fitz.

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. 🚀

from go-fitz.

@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.

from go-fitz.

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.

from go-fitz.

@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.

from go-fitz.