search

msys2 / MINGW-packages

Package scripts for MinGW-w64 targets to build under MSYS2.
https://packages.msys2.org
BSD 3-Clause "New" or "Revised" License
2.31k stars 1.23k forks source link

gpgme: disable docs for CLANGARM64 environment #22442

Closed mmuetzel closed 3 weeks ago

mmuetzel commented 3 weeks ago

Building fails in the CLANGARM64 environment with a segfault(?) when trying to run one of the generator executables built during the build process:

  incd="`test -f defsincdate || echo './'`defsincdate"; \
  ./mkdefsinc -C . --date "`cat $incd 2>/dev/null`" \
      gpgme.texi uiserver.texi lesser.texi gpl.texi >defs.inc
  mkdefsinc: taking date from 'gpgme.texi'
  make[2]: *** [Makefile:905: defs.inc] Error 139

Disable building the documentation for the CLANGARM64 environment as a workaround.

mmuetzel commented 3 weeks ago

I can't test if that actually fixes the build issue for CLANGARM64. But when I applied the patch locally, I didn't see mkdefsinc being called anywhere during the build process.

Maybe, we could merge and wait whether it builds now for staging...

Biswa96 commented 3 weeks ago

The build log can be found here https://github.com/msys2-arm/msys2-autobuild/actions/runs/11716642221/job/32635080436#step:11:1585

jeremyd2019 commented 3 weeks ago

OK, here's what's happening: this snprintf call is failing https://github.com/gpg/gpgme/blob/32b4e4a9b5381ca06b6633035479a07aad9071c8/doc/mkdefsinc.c#L265-L266

I found this note on MSDN (right above https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-170#flags):

Because the %n format is inherently insecure, it's disabled by default. If %n is encountered in a format string, the invalid parameter handler is invoked, as described in Parameter validation. To enable %n support, see _set_printf_count_output.

Either passing -Wp,-D__USE_MINGW_ANSI_STDIO=1 when building mkdefsinc or adding a call to _set_printf_count_output(1); right before that snprintf call works. This leaves the question of why it worked before, and why it works on other UCRT environments. Is this a really recent Windows update? One thing is that it only seems to use CPPFLAGS, probably because it is a "build" tool rather than "target" so the target's CFLAGS might not be applicable on the build host. (https://github.com/gpg/gpgme/blob/32b4e4a9b5381ca06b6633035479a07aad9071c8/doc/Makefile.am#L49) Maybe moving __USE_MINGW_ANSI_STDIO out of CPPFLAGS broke it? Still doesn't explain why it works on CLANG64/UCRT64.

mmuetzel commented 3 weeks ago

Thank you for the detective work! Nice find. 👍

I also don't understand why this is only an issue on Windows on ARM. Does mingw-w64 have any workarounds in place that aren't effective for that target?

In any case, does that mean that adding -D__USE_MINGW_ANSI_STDIO=1 to the CPPFLAGS in the packaging rules would also fix it? If it does, that would probably be a better fix than the work-around that was applied here.

jeremyd2019 commented 3 weeks ago

Huh, just noticed that respecting CPPFLAGS in mkdocsinc was added in https://github.com/msys2/MINGW-packages/pull/4302, and https://github.com/msys2/MINGW-packages/issues/4165#issuecomment-413152233 has the same analysis (and notes this also applies to gpg. don't know much about mingw-w64-gpg, iirc it was broken anyway)

jeremyd2019 commented 3 weeks ago

I wonder if this was the segfault mentioned in #1975