It turns out that we do not need to have separate command lines for
running the Visual Studio preprocessor for 32-bit builds and 64-bit
builds as `_WIN64` is automatically defined by the 64-bit compilers.
This means that we can clean up the project files a bit.
GTK2 uses different gtk.def files on 32-bit and 64-bit Windows. GTK2
source tarballs ship pre-generated gtk.def for 32-bit Windows. If the
user wants to build for 64-bit Windows, the pre-generated gtk.def must
be deleted before the build to force regeneration, or it will fail to
link with 'symbol not defined' errors because the 32-bit Windows build
includes more legacy functions than the 64-bit Windows build.
While users who want to build for 64-bit Windows can delete gtk.def in
the build script, which is currently what most build scripts do, doing
so breaks out-of-source build. On AUR, MinGW packages are usually built
and packaged in the following order:
1. Run 'configure' and 'make' to build for i686-w64-mingw32.
2. Run 'configure' and 'make' to build for x86_64-w64-mingw32.
3. Run 'make install' for i686-w64-mingw32.
4. Run 'make install' for x86_64-w64-mingw32.
It fails because step 3 sees gtk.def left by step 2, which is generated
for a different build. In step 3, make sees the gtk.def change and runs
libtool to relink libgtk-win32-2.0-0.dll. libtool fails to find a lot of
necessary libraries, decides that it is not possible to build a DLL with
-no-undefined, and produces only the static library. It then tries to
relink executables with the static library, and fails with undefined
reference to 'IID_IUnknown' because -Wl,--start-group isn't used and
the use of -Wl,-luuid prevents libtool from using the correct order.
To resolve the problem, move gtk.def to builddir so different builds can
have different gtk.def files while sharing the same source tree. This
also means that the source tarball will no longer include pre-generated
gtk.def file, which should be acceptable because it is already broken on
64-bit Windows.
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/3029
Fixes https://gitlab.gnome.org/GNOME/gtk/-/issues/2684
GIMP segfaults while switching themes between dark and gray and inputting Ctrl-O
to open a file. This is because p advances past end of pixbuf in pixbuf-render.c
compute_hint() with num_channels = 3 (no alpha). This is resolved by fixing the
if statement to only check for alpha, thereby advancing p, if there is an alpha
channel.
In the Vietnamese Quoted-Readable input method, punctuation following a
base letter is converted into diacritical marks, for example a( → ă.
(See <https://en.wikipedia.org/wiki/Vietnamese_Quoted-Readable>.)
A 2008 bug report in Ubuntu argued that this is a problematic default,
particularly when typing passwords, where the effect of the punctuation
is non-obvious.
According to the bug reporter, VIQR is popular with Vietnamese users
living elsewhere in the world, where Vietnamese keyboards are unlikely
to be readily available, but is not a popular choice within Vietnam,
where the Telex or VNI input modes are preferred.
Closes: #183
Bug-Debian: https://bugs.debian.org/895043
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/191451
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
Commit 6ae3082603 included some changes from the gtk-3-24 branch that
do not make sense in the context of the commit, and break the build of
GTK 2 on Windows. The delta_x and delta_y fields do not exist in the
GdkEventScroll in the gtk-2-24 branch.
Segfault occurred when displaying two windows on different X11 displays.
valgrind said:
Invalid read of size 8
at 0x4A20962: _gtk_style_init_for_settings (gtkstyle.c:398)
by 0x49ED785: gtk_rc_get_style (gtkrc.c:2036)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Address 0x70b8e80 is 560 bytes inside a block of size 1,024 free'd
at 0x48399AB: free (vg_replace_malloc.c:530)
by 0x51180D6: g_type_free_instance (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x49E98CE: gtk_rc_reset_styles (gtkrc.c:1702)
by 0x49E9A0C: _gtk_rc_context_get_default_font_name (gtkrc.c:1740)
by 0x4A20961: _gtk_style_init_for_settings (gtkstyle.c:396)
by 0x49ED785: gtk_rc_get_style (gtkrc.c:2036)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Block was alloc'd at
at 0x483877F: malloc (vg_replace_malloc.c:299)
by 0x51BD289: g_malloc (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x519F673: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x51A62BA: g_slice_alloc0 (in /usr/lib/libglib-2.0.so.0.6000.6)
by 0x5119141: g_type_create_instance (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x513563D: ??? (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x5136A54: g_object_new_with_properties (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x5136B51: g_object_new (in /usr/lib/libgobject-2.0.so.0.6000.6)
by 0x49ED774: gtk_rc_get_style (gtkrc.c:2035)
by 0x4AC39C2: gtk_widget_reset_rc_style (gtkwidget.c:6601)
Copy and update the relevant fields from the Visual Studio 2010 projects
so that we can have project files that work out-of-the-box for Visual
Studio 2019, as we did for Visual Studio 2012 through 2017.
Also update the NMake Makefiles for building the introspection files
so that we properly detect that we are building with Visual Studio 2019.
CREATEPROCESS_MANIFEST_RESOURCE_ID is a macro defined in winbase.h,
so we need an include to resolve that macro to its value, 1.
Without that it stays as a literal CREATEPROCESS_MANIFEST_RESOURCE_ID,
and ends up in the .exe file as-is, and Windows can't find it by that name,
resulting in UAC manifest not working and gtk-update-icon-cache bringing
up UAC prompt.
including when the control modifier is present, i.e. when one is typing
control-I for instance.
Orca would convert them back to the corresponding ASCII letter anyway, and
when pressing control-tab, we do want to pass "tab", not pass "\t" that Orca
would erroneously convert to "control-I".
Fixes#1743
(cherry picked from commit 728f6869cb)
This updates the introspection build process that we also check on
changes in the Makefiles when we generate the NMake Makefile snippets
and file lists, so that any changes to the source file list can be
reflected. Also ensure that we build against the freshly-built
libraries.
Make the NMake Makefiles also output the built introspection items to
the output directories of the various Visual Studio versions, according
to the build configuration and architecture, so that we avoid confusion
for different Visual Studio build configs.
In GLib-2.57.3 and later, GStatBuf may not be a struct stat on Windows,
depending on the architecture and the compiler used, so we can't just
call fstat() on the GStatBuf.
Instead, we need to use the correct CRT function to call on the
GStatBuf, which is as follows:
-_fstat32() for Windows 32-bit builds on mingw-w64 and MSVC
-_fstat64() for Windows 64-bit builds on mingw-w64
-stat() for Windows 64-bit builds on MSVC, and on all other platforms.
We are not passing in the correct architecture to the script that we use
to generate the pkg-config files for Release/x86 builds and Debug/x64
builds. Fix this.
Just link to Cairo instead of looking for the Cairo .pc file as the
Cairo build system for Visual Studio currently does not generate a
pkg-config file for us. This will eliminate the need to hand-craft a
pkg-config file for Cairo to be able to use the pkg-config files that we
generate here.
Don't pass in G_LOG_DOMAIN=\"...\" to the CFlags that is passed into the
generation the NMake Makefiles. This will avoid the introspection scanner
from choking because the resulting NMake Makefiles may not have that
CFlag escaped properly, and it is not really needed for building the
introspection binary.
Replace "stat struct" with "GStatBuf" and "stat" with "g_stat" where
appropriate to fix cross-platform issues, specifically on Windows.
Code should be identical on *nix but fixes some serious issues
on Windows:
- Field widths of "struct stat" are not constant on Windows.
If the stat function does not match the stat struct used
it will cause overwrites and undefined behavior
- The Windows stat function needs a properly encoded filename.
In many places we pass an UTF-8 encoded value which breaks as soon
as non-ASCII characters are involved.
https://bugzilla.gnome.org/show_bug.cgi?id=787772
