Arch Linux User Repository

I added this

ifndef _Countof

define _Countof(x) (sizeof(x) / sizeof((x)[0]))

endif

to src/gettext-0.26/gettext-tools/gnulib-lib/options.h after

ifndef _OPTIONS_H

define _OPTIONS_H

and it compiles. I am wondering if moving to 1.0 might break other packages.

@dkeruza I've just updated to 1.0 which builds for me.

It wont compile. In file included from ../../../gettext-tools/src/../woe32dll/../src/msgmerge.c:36, from ../../../gettext-tools/src/../woe32dll/c++msgmerge.cc:1: ../../../gettext-tools/src/../woe32dll/../src/msgmerge.c: In function ‘int main(int, char**)’: ../../../gettext-tools/gnulib-lib/options.h:227:57: error: ‘_Countof’ was not declared in this scope; did you mean ‘_countof’? 227 | struct option _gl_long_options[_GL_LONG_OPTIONS_SIZE (countof (options))]; \ | ^ ../../../gettext-tools/gnulib-lib/options.h:233:40: note: in definition of macro ‘_GL_LONG_OPTIONS_SIZE’ 233 | #define _GL_LONG_OPTIONS_SIZE(count) ((count) + 1) | ^ ../../../gettext-tools/src/../woe32dll/../src/msgmerge.c:221:3: note: in expansion of macro ‘start_options’ 221 | start_options (argc, argv, options, MOVE_OPTIONS_FIRST, 0); | ^ ../../../gettext-tools/gnulib-lib/options.h:231:22: error: ‘_gl_long_options’ was not declared in this scope; did you mean ‘_gl_start_options’? 231 | _gl_long_options, _gl_short_options, \ | ^~ ../../../gettext-tools/src/../woe32dll/../src/msgmerge.c:221:3: note: in expansion of macro ‘start_options’ 221 | start_options (argc, argv, options, MOVE_OPTIONS_FIRST, 0); | ^ ../../../gettext-tools/gnulib-lib/options.h:231:40: error: ‘_gl_short_options’ was not declared in this scope; did you mean ‘_gl_start_options’? 231 | _gl_long_options, _gl_short_options, \ | ^ ../../../gettext-tools/src/../woe32dll/../src/msgmerge.c:221:3: note: in expansion of macro ‘start_options’ 221 | start_options (argc, argv, options, MOVE_OPTIONS_FIRST, 0); | ^

Good news! Thank you!
I'll check it out soon.

UPD. Now application run fine! Thanks!

I was able to reproduce the issue and pushed a patch which fixes the problem.

Ok, good to know. I've just checked the library name and it hasn't changed between the different versions (it is and was libintl-8.dll).

I don't think a complete list of packages is required. It looks like libintl-8.dll is used by harfbuzz and glib2 (see https://martchus.dyn.f3l.de/buildservice/?#package-search-section?name=pe-x86_64%3A%3Alibintl-8.dll&mode=libdepends) and hence also indirectly loaded when starting a Qt application.

I'll see whether I can reproduce the problem when I have time.

All my package install from you repositories - mingw-w64-gettext, mingw-w64-glib2, mingw-w64-qt5-... and other for cross compiling for Windows.
Package mingw-w64-gettext version 0.22.5 too (get from my local packages cache). Application is completely rebuilt every time.
Provide a complete list of installed packages from your repository?

My repo is actually also already at version 0.24. Maybe the library name has changed so packages have to be rebuilt. However, normally my build service should catch that. So maybe there's something else wrong. I'll have a look when I'll find the time.

According to https://martchus.dyn.f3l.de/buildservice/#package-details-section?ownstuff%40x86_64%2Fmingw-w64-qt5-base Qt 5 does not even link against that library. What are you actually trying to run here?

Hello. After update to version 0.24 not run qt5 cross compiled application in windows - The Procedure DllMain Entry Point Could Not Be Located in DLL libintl-8.dll. Downgrade to version 0.22.5 solvet problem. Package setup from Martchus repositories.

The explanation on why my problem appears is explained here: https://aur.archlinux.org/packages/mingw-w64-curl#comment-965703. tl;dr, having wine installed does cause this issue, because then you can run windows binaries and configure doesn't detect that we are cross-compiling (and doesn't skip the runtime checks).