The `%I64` printf format family is a Windows-specific extension that has
been handled for, like, eternity in `mingw-w64-gettext`. But the recent
update to v0.22.3 broke that.
The reason for that is a story of two episodes:
- gnulib slipped in a major refactoring of the `printf()` format parsing
into a commit whose purpose was to support new size specifiers:
https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=480a59ba60fa0b43a1cebe218bbcea6a947f1e86
Unfortunately, the code handling `%I64` was converted incorrectly,
where it previously skipped the `64` part before looking for the
conversion specifier (correct) but now no longer does so (incorrect):
https://git.savannah.gnu.org/cgit/gnulib.git/diff/lib/printf-parse.c?id=480a59ba60fa0b43a1cebe218bbcea6a947f1e86
- gettext saw a major refactoring with the intention to avoid
duplicating gnulib's `printf()` logic, dropping its own code in favor
of the latter:
https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commitdiff;h=a80b9021019fe311b81771d67138496f512ef35a
The result is that as of `mingw-w64-gettext` v0.22.3, `%I64d` is
_started_ to be parsed but then fails because it mistakes `6` for the
conversion character (instead of recognizing `d` as such).
Work around this regression by skipping the `64` part again.
This patch needs to be upstreamed to the gnulib project, yet we need to
fix the `mingw-w64-gettext` regression at a more timely pace and need to
integrate the patch early.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
For example msgfmt and other tools would fail with "-o nul" which
previously worked.
Backport two gnulib patches which fix this regression.
Fixes#10520
They are declared, after all.
Fun fact: in v0.19.8.1, those functions were included in the library,
but not declared in the header. In v0.21 the were _not_ included in the
library, but they _were_ declared in the header.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
relocate() in gnulib-lib needs INSTALLDIR and INSTALLPREFIX to be
Windows paths so it can relocate the input.
Fix by removing INSTALLPREFIX from MSYS2_ARG_CONV_EXCL so it gets
converted when passed to the compiler and pass it to gnulib-lib,
and convert INSTALLPREFIX in gettext-tools/config.h manually.
Fixes#4392 (for real, hopefully)
According to bindtextdomain man passing NULL is allowed
and must be interpreted as current value request.
This behaviour is implemented in non-patched bindtextdomain version.
The relocatable bindtextdomain implementation crashed in strrchr()
call when dirname==NULL was passed: it tried to relocate
NULL dirname (and strdup(NULL) returns NULL).
This patch disables relocation attempt if dirname=NULL.
The user-visible problem that lead to the crash is NOT tightly-related.
I was using VERY experimental mingw64 location on win7: gedit.exe from
"D:\m\noshortname with spaces and non ascii абвг ææ\msys2\mingw64\bin\"
where "D:\m\noshortname with spaces and non ascii абвг ææ\msys2"
is a junction to the actual msys2 root D:\apps\msys2 and
"noshortname with spaces and non ascii абвг ææ" has no short 8.3-name.
Understanding that this is NOT very useful scenario,
I think that bindtextdomain should handle NULL value according to man
since it may lead to another problems in "normal" usages
if some app would call it with NULL (as allowed in the docs).
I didn't investigate why gtk passes NULL as a dirname in this setup,
but after this libintl fix - gedit.exe starts fine.
(even more - it started from link with non-BMP characters in its name)
* upgrade some broken packages
* correct some broken urls/checksums
* use secure urls where possible
* update PKGBUILD templates
* remove line-ending whitespace
* minor typos/fixes
Remaining md5sums either didn't download or
didn't pass checksum tests.
On the surface, this patch looks as if it only fixes a compile warning:
the canonicalize_file_name() and win2unixpath() functions are used
without having them declared. Everything still compiles fine, and
cursory testing in most setups shows that everything is fine.
Except that it is not.
When GCC sees that canonicalize_file_name() is used without a
declaration, it will assume implicitly that the return value is an int.
A 32-bit one, to be precise. So when those two functions return a
pointer (a 64-bit one), the most significant 32 bits are simply cut off.
Except they are not cut off: they are left in the state as before.
This developer encountered this issue in the form of a segmentation
fault when running with the FLG_LDR_TOP_DOWN enabled [*1*], because the
machine register holding the return value still held a 0xffffffff from
the return address.
Footnote *1*:
https://technet.microsoft.com/en-us/library/cc779664%28v=ws.10%29.aspx
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This commit does nothing else than turning the former context-diff
formatted patch into a proper unified diff, to make the next patch
easier to review.
While at it, let's just turn it into a Git-style patch, with commit
message.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The `libintl-8.dll` file from mingw-w64-x86_64-gettext 0.19.5.1-1 has
the path `D:/develop/msys64/mingw64/share/locale` hard-coded. As a
consequence, programs that link to libintl-8.dll may try to open said
directory. In many setups, `D:\` actually refers to a CD/DVD drive which
means that the user may see this nasty error message:
There is no disk in the drive. Please insert a disk into drive D:
Let's not do that, but instead hard-code the *POSIX* path into that
`.dll` file, i.e. `/mingw64/share/locale`.
This fixes https://github.com/git-for-windows/git/issues/329
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
License files are now installed for the following packages:
* atk
* cairo
* enchant
* freetype
* gdk-pixbuf2
* gettext
* glib2
* gtk2
* gtkspell
* libiconv
* libxml2
* meanwhile
* pango
* perl
* shared-mime-info
The following packages now specify license more explicitly:
* cairo is LGPL2.1 or MPL1.1.
* gettext is GPL3 with LGPL2.1 parts.
* gtkspell and shared-mime-info are GPL2.
* atk, gdk-pixbuf2, glib2, gtk2 and meanwhile are LGPL2.
* perl is GPL1+ or Artistic1 ("Artistic License" not "Perl Artistic").
The license field has been fixed for the following packages:
* drmingw and drmingw-git: GPL does not apply anymore.
* enchant: it seems to be plain LGPL2.1 without later versions.
* freetype: the FreeType license can also be used.
* libiconv: both GPL3 and LGPL2 apply at the same time.
* libxml2: this is MIT not LGPL.
* pango: LGPL seems to apply only partially, unclear license for the rest.
