Visual Studio, at least the older versions, cannot use L on macros which
are defined as a constant string, plus the L must be applied to all string
literals here. This does not look nice, but this is life...
Rather than calculating it at configure time. This means it can expand
$libdir properly, and use the Make $(realpath) function rather than
invoking the non-portable `readlink -f`.
This fixes problems where `readlink` would be called on an invalid path
(due to a variable not being expanded) and would evaluate to "", which
would then cause things to be installed in the wrong place.
https://bugzilla.gnome.org/show_bug.cgi?id=744772
... for builds using the PCRE bundled with the GLib sources, so that
pcre_version() will also be defined, and be exported so that the regex test program
will properly link when the bundled PCRE sources are used.
This is a follow-up commit to 476f30a.
This reverts commit a3a9664ed2.
Constifying the autogenerated get_instance_private functio makes C++
compilers and GCC with -Wcast-qual warn during compilation of GLib and
projects depending on GLib.
Since using const with GObject instances is not a common coding
practice, it's better to revert than trying to make every sigle GType
function const-safe (and possibly add more compiler warnings in the
process).
https://bugzilla.gnome.org/show_bug.cgi?id=745068
This reverts commit 52f23db74a.
Constifying these macros make C++ compilers and GCC with -Wcast-qual
warn during compilation of GLib and projects depending on GLib.
Since using const with GObject instances is not a common coding
practice, it's better to revert than trying to make every sigle GType
function const-safe (and possibly add more compiler warnings in the
process).
https://bugzilla.gnome.org/show_bug.cgi?id=745068
Add a new GDtlsConnection interface, plus derived GDtlsClientConnection
and GDtlsServerConnection interfaces, for implementing Datagram TLS
support in glib-networking.
A GDtlsConnection is a GDatagramBased, so may be used as a normal
datagram socket, wrapping all datagrams from a base GDatagramBased in
DTLS segments.
Test cases are included in the implementation in glib-networking.
https://bugzilla.gnome.org/show_bug.cgi?id=752240
This is a follow-up commit for commit 82c2461, where the default build is
to use the PCRE that is installed in the system, if it is available and is
not overridden with --with-internal-pcre.
For Visual Studio builds, this means that the new 'Debug' and 'Release'
configs will now use PCRE that is found on the system, which were renamed
from the '*_ExtPCRE' configs; and that there are now 'Debug_BundledPCRE'
and 'Release_BundledPCRE' configs which make use of the PCRE that is
supplied with the GLib sources, which, replaces the former 'Debug' and
'Release' configs.
Commit 855594c changed the expected error for the regex
/(?P<sub>foo)\g<sub/ for PCRE 8.38, but actually PCRE changed the error
raised by this invalid regex in 8.37, so we should check for the new error
from 8.37 and upwards.
Please see comments #21 and #22 of bug 740573 regarding this commit.
To be honest, i don't remember what problems were caused by it returning the
number of bytes it *wanted* to write instead of the number of bytes
it actually wrote. Probably related to the fact that fwrite could
independently fail, and ignoring its return value ignores that error.
https://bugzilla.gnome.org/show_bug.cgi?id=748064
PCRE 8.38 changed the parsing of this invalid regex. It still fails,
but with a different error (since PCRE r1539,
<http://vcs.pcre.org/pcre?view=revision&revision=1539>).
The regex /(?P<sub>foo)\g<sub/ used to raise MISSING_BACK_REFERENCE but
now raises MISSING_SUBPATTERN_NAME_TERMINATOR, so we can still have a
test for the latter.
Signed-off-by: Simon McVittie <smcv@debian.org>
Reviewed-by: Emmanuele Bassi <ebassi@gnome.org>
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=759808
We changed the behaviour of this API to adapt to a change in the D-Bus
specification. Document the new behaviour, along with the time of the
change.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
gdbus sets NO_REPLY_EXPECTED when no callback is given to
g_dbus_connection_call(). It makes sense that it also handles the server
side correctly by discarding replies to clients that don't want one.
https://bugzilla.gnome.org/show_bug.cgi?id=755421
This causes several problems:
- Compilation in FreeBSD with --enable-gtk-doc broke
- Modules that still use the AM_GLIB_GNU_GETTEXT macro
doesnt compile anymore because /usr/share/glib-2.0/gettext
is not filled with the correct files, as this was done in
the glib custom po/Makefile.in.in
See https://bugzilla.gnome.org/show_bug.cgi?id=622991
This reverts commit e5c752371c.
Its documentation mentions that it logs a 'critical warning', but since
the macro implementation calls g_warn_message(), it does not log a
critical message, but a regular warning.
