Search Criteria
Package Details: mingw-w64-gettext 0.22.5-1
Package Actions
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) |
Dependencies (4)
- mingw-w64-libunistringAUR
- mingw-w64-termcapAUR
- gettext (gettext-gitAUR) (make)
- mingw-w64-configureAUR (llvm-mingw-w64-configureAUR) (make)
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):libiconv-2.dll does exist, it's just that wine doesn't have the correct prefix. With this patch:
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:
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:
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 ?
1 2 3 4 5 6 .. 9 Next › Last »