This commit broke some tests, and I don't have the time
to fix up all the expected output, so I'll revert the changes
to the affected files for now.
This needs to be redone with the necessary test fixes.
Make the Makefile.am targets for generating the Visual Studio projects re-generate the
project files and the header listings whenever the Makefile.am's that include
build/Makefile.msvcproj changes, so that whenever a source/header is added, they will
be reflected in the projects and in the property sheets that are used to copy the
headers.
Also ensure that these are applied to the vs11, vs12 and vs14 projects when this
happens, as they are copied and processed from the Visual Studio 2010 projects.
So that we don't get "deprecation" (availability) warnings for
new functionality of GLib 2.51/2.52.
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
I'm guessing the developments were done in 2.44 but the patches landed
after the 2.45.0 bump without an update to the Since tags.
Signed-off-by: Damien Lespiau <damien.lespiau@intel.com>
https://bugzilla.gnome.org/show_bug.cgi?id=769630
GLib has g_unix_mount_at (mount_path) already, let's add g_unix_mount_for
(file_path) for whatever path. GLib already contains some private code
for such task. Let's make this code public. This functionality is needed
by GVfs (see Bug 771431) in order to avoid copy-and-pasting.
https://bugzilla.gnome.org/show_bug.cgi?id=772160
A windows application compiled with -Wl,--subsystem,windows has no
console attached. When started from the start menu for ex, it will crash
when a function attempt to use g_log:
#10 0x00a21b26 in g_logv (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed", args=0x28f2bc "PG"")
#11 0x00a21bb1 in g_log (log_domain=0xa842e1 <__func__.7668+329> "GLib", log_level=G_LOG_LEVEL_CRITICAL, format=0xa845c6 <__func__.7668+1070> "%s: assertion '%s' failed") at gmessages.c:1337
#12 0x00a22bac in g_return_if_fail_warning (log_domain=0xa842e1 <__func__.7668+329> "GLib", pretty_function=0xa84750 <__func__.65002> "g_log_writer_supports_color",
expression=0xa844de <__func__.7668+838> "output_fd >= 0") at gmessages.c:2453
#13 0x00a2239e in g_log_writer_supports_color (output_fd=-2) at gmessages.c:1826
#14 0x00a226ac in g_log_writer_standard_streams (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2254
#15 0x00a2290e in g_log_writer_default (log_level=G_LOG_LEVEL_WARNING, fields=0x28f3c8, n_fields=4, user_data=0x0) at gmessages.c:2357
According to https://msdn.microsoft.com/en-us/library/zs6wbdhx.aspx:
If stdout or stderr is not associated with an output stream (for
example, in a Windows application without a console window), the file
descriptor returned is -2. In previous versions, the file descriptor
returned was -1. This change allows applications to distinguish this
condition from an error.
Check if the stream exists and has an associated descriptor and return
G_LOG_WRITER_UNHANDLED if it's not the case.
Fixes:
https://bugzilla.gnome.org/show_bug.cgi?id=772511
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There have been some improvements to the tool recently, but it's hard to
know if those are available on a given system unless the tool provides a
--version commandline option.
https://bugzilla.gnome.org/show_bug.cgi?id=772269
It only works through its virtual methods, so while it could be
instantiated before (and this is technically an API break), any instance
of it would previously have crashed as soon as any of its methods were
called anyway.
If anybody has any problems with this ABI break, please make them known
during the 2.51 unstable development cycle and it can be reverted.
https://bugzilla.gnome.org/show_bug.cgi?id=772255
/proc/self/mountinfo is used to monitor changes of mounts with libmount.
However, GFileMonitor is used currently to monitor this file, which
doesn't work and consequently "changed" signal is never emitted. Special
monitoring needs to be used instead, same as it is used for /proc/mounts.
https://bugzilla.gnome.org/show_bug.cgi?id=662946
It turns out that CommandLineToArgvW() (at least on XP) doesn't end the argv
pointer array with a NULL, but goes straight into argv[0] string data, as per
MSDN. So gspawn-win32-helper.c:protect_wargv() counts argc too high and
overflows.
https://bugzilla.gnome.org/show_bug.cgi?id=772054
