Package Details: mingw-w64-gettext 0.22.5-1

Git Clone URL: https://aur.archlinux.org/mingw-w64-gettext.git (read-only, click to copy)
Package Base: mingw-w64-gettext
Description: GNU internationalization library (mingw-w64)
Upstream URL: http://www.gnu.org/software/gettext/
Licenses: GPL-2.0-only, GPL-2.0-or-later, LGPL-2.0-only, GFDL-1.2-only
Submitter: brcha
Maintainer: xantares (Martchus)
Last Packager: Martchus
Votes: 27
Popularity: 0.000000
First Submitted: 2012-06-13 18:20 (UTC)
Last Updated: 2024-08-01 18:15 (UTC)

Latest Comments

1 2 3 4 5 6 .. 9 Next › Last »

syyyr commented on 2024-04-08 09:31 (UTC)

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

Martchus commented on 2024-04-04 14:36 (UTC) (edited on 2024-04-04 14:37 (UTC) by Martchus)

I recommend building in a clean chroot using makechrootpkg like official devs do. That's also how packages in my binary repository are built and what works for me. Note that in this environment WINE wouldn't even be installed (at least not for this package as it doesn't depend on it). Maybe you have something installed/configured in your build environment that makes the configuration script think it should/can run certain configuration tests when it actually cannot. (Having WINE installed in the build env shouldn't cause this issue on its own, though.)

syyyr commented on 2024-04-04 10:28 (UTC) (edited on 2024-04-04 12:37 (UTC) by syyyr)

Hi, right now, building this package gives me errors about undefined references to iconv_ostream_create. I found out that the configure script doesn't correctly detect iconv: it prints out "checking for working iconv... no". The reason it doesn't detect it is that after compiling the test program via i686-w64-mingw32-gcc, the script fails to run the program with these errors (from config.log):

01fc:err:module:import_dll Library libiconv-2.dll (which is needed by L"Z:\\home\\vk\\.local\\aur\\mingw-w64-gettext\\src\\gettext-0.22.5\\build-i686-w64-mingw32\\gettext-runtime\\conftest.exe") not found
01fc:err:module:loader_init Importing dlls for L"Z:\\home\\vk\\.local\\aur\\mingw-w64-gettext\\src\\gettext-0.22.5\\build-i686-w64-mingw32\\gettext-runtime\\conftest.exe" failed, status c0000135

libiconv-2.dll does exist, it's just that wine doesn't have the correct prefix. With this patch:

diff --git a/PKGBUILD b/PKGBUILD
index f62e8b3..2edf430 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -28,7 +28,7 @@ build() {
   for _arch in ${_architectures}; do
     mkdir -p build-${_arch} && pushd build-${_arch}
     export MINGW_LDFLAGS="-Wl,--enable-auto-import"
-    LIBS="-lssp" ${_arch}-configure \
+    WINEPATH=/usr/${_arch}/bin LIBS="-lssp" ${_arch}-configure \
       --disable-java \
       --disable-native-java \
       --disable-csharp \

iconv gets properly detected, and I was able to successfully build mingw-w64-gettext then. I unfortunately don't think this is how things should be done. It could be that I did something to my system and the wine prefix isn't available when building AUR packages. Any ideas?

edit: In mingw-w64-curl, there seems to be a similar problem: https://aur.archlinux.org/packages/mingw-w64-curl#comment-964645

DarkShadow44 commented on 2024-03-27 20:10 (UTC)

@xantares: The comment from "patlefort" was from before the "Fix checksum" commit got pushed, it's fixed now.

xantares commented on 2024-03-27 19:57 (UTC)

works fine here, maybe a network glitch ?

patlefort commented on 2024-03-26 22:20 (UTC)

Checksum fails:

    gettext-0.22.5.tar.gz ... FAILED
    gettext-0.22.5.tar.gz.sig ... Skipped
    intl.pc ... Passed
==> ERROR: One or more files did not pass the validity check!

Martchus commented on 2021-04-01 15:09 (UTC)

@stt You've already noticed yourself that it hangs when building libiconv. That means the comment would be better placed under the mingw-w64-libiconv package. Apparently another user has already noticed the same problem there. Note that I haven't run into the problem last time I built the package (So 17 Mai 2020).

stt commented on 2021-04-01 14:35 (UTC) (edited on 2021-04-02 02:46 (UTC) by stt)

Build is failing - its locking up after linking libiconv and is never finishing.

Last lines of the build:

libtool: link: i686-w64-mingw32-gcc -Wl,-O1 -Wl,--sort-common -Wl,--as-needed -fstack-protector -D_FORTIFY_SOURCE=2 -O2 -pipe -fno-plt -fexceptions --param=ssp-buffer-size=4 iconv_no_i18n.o iconv.res -o .libs/iconv_no_i18n.exe  ../srclib/libicrt.a ../lib/.libs/libiconv.dll.a -L/usr/i686-w64-mingw32/lib
test `ls -ld . | sed -e 's/^d\(.........\).*/\1/'` = rwxrwxrwx || chmod 777 .
make[1]: Leaving directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/src'
cd po && make all
make[1]: Entering directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/po'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/po'
cd man && make all
make[1]: Entering directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/man'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/man'
if test -d tests; then cd tests && make all; fi
make[1]: Entering directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/tests'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/home/twigger/.cache/yay/mingw-w64-libiconv/src/libiconv-1.16/build-i686-w64-mingw32/tests'

Full build log: https://pastebin.com/JgGUXTQ6

gerum100 commented on 2021-01-06 15:15 (UTC)

Thanks for your fast answer, and sorry, I thought the error was in this package, but in fact it was in another one.

xantares commented on 2021-01-06 13:03 (UTC)

I cannot reproduce, can you post the error ?