At some point, upstream SystemTap changed from using a
STAP_HAS_SEMAPHORES preprocessor variable for this, to using
_SDT_HAS_SEMAPHORES instead. We need to update our build system to
disable that as well.
The original discussion about use of semaphores is here:
https://bugzilla.gnome.org/show_bug.cgi?id=606044
This was breaking the build with -flto enabled, either because -flto
doesn’t work with semaphores.
https://bugzilla.gnome.org/show_bug.cgi?id=768198
The C spec leaves conditional evaluation inside a macro expansion as
undefined behaviour. This means we cannot use constructs like:
GOBJECT_IF_DEBUG(OBJECTS, {
...
#ifdef BLAH
...
#endif
...});
Because compilers are entirely justified to ignore the conditional, or,
like in the case of MSVC, error out.
https://bugzilla.gnome.org/show_bug.cgi?id=769504
historically, DEBUG_CODE(gtype.c) and IF_DEBUG(gobject.c, gsignal.c)
macros are used to support debugging messages about object bookkeeping
and signal emission.
DEBUG_CODE has never been used in gtype.c. IF_DEBUG, when used, must be
accompanied by an extra #ifdef G_ENABLE_DEBUG. this is cumbersome.
this patch add a new macro GOBJECT_IF_DEBUG based on DEBUG_CODE as
a replacement for both DEBUG_CODE and IF_DEBUG.
https://bugzilla.gnome.org/show_bug.cgi?id=729914
In a vague attempt at ensuring the .stp scripts can be closely
associated with the .so files which they hard-code references to, rename
the scripts so they include the LT version — so that they are the .so
file name plus .stp.
This does not fix the fact that our .stp scripts will not work on
multiarch systems, as they are installed in an architecture-independent
directory (/usr/share/systemtap/tapset). At the moment, it is
recommended that any distribution who package the .stp files should
install them in the architecture-specific subdirectories of this (for
example, /usr/share/systemtap/tapset/x86-64).
A better long-term solution for this is under discussion upstream:
https://sourceware.org/bugzilla/show_bug.cgi?id=20264https://bugzilla.gnome.org/show_bug.cgi?id=662802
The ability to pass libtool via $(CC) to dtrace and have it respect this
appears to be a feature that is only present in the systemtap version of
the tool. In particular, FreeBSD (which seems to be using a copy of the
tool from Solaris) doesn't support this.
The result is that, with $(CC) ignored, and a .lo file specified in -o,
we get an ELF written to the .lo.
Instead of trying to have dtrace run libtool we can have libtool run
dtrace. dtrace is really just a compiler that produces an object file
here, and it even understands -o, so libtool can make the appropriate
adjustments.
There appears to be some prior art for this approach. A quick search
shows that at least QEMU is using this approach. It also appears to
work on Linux with systemtap's dtrace and on FreeBSD.
This may regress cross-compilation because the dtrace command will have
no way of knowing which compiler we intend for it to use to produce the
object file. I say "may" because I don't know if dtrace ever worked in
the first place under cross-compilation.
https://bugzilla.gnome.org/show_bug.cgi?id=725902
Some compilers have trouble with such sequences. Visual C++ may or may
not generate a warning in this particular case depending on if the
local code page supports an ellipsis.
https://bugzilla.gnome.org/show_bug.cgi?id=767218
glib installs a gdb helper file named `glib.py`.
Then the "hook" file updates `sys.path` and does `import glib`.
This will fail if glib has already been imported into gdb, say
using `from gi.repository import GLib`. This is due to a namespace clash.
One fix would be to rename the gdb helper files to not clash with
other Python modules. This should be done for all such helper files.
https://bugzilla.gnome.org/show_bug.cgi?id=760186
v_long is 32 bits on Win64, v_pointer is 64 bits. On most other platforms the
size of long and pointer is the same, so it's usually not a problem.
https://bugzilla.gnome.org/show_bug.cgi?id=758738
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
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 ref-func, unref-func, set-value-func, and get-value-func annotations to
GParamSpec so that it can be managed generically as a fundamental type with
introspection.
https://bugzilla.gnome.org/show_bug.cgi?id=710243
Add various (nullable) and (optional) annotations which were missing
from a variety of functions. Also port a couple of existing (allow-none)
annotations in the same files to use (nullable) and (optional) as
appropriate instead.
Secondly, add various (not nullable) annotations as needed by the new
default in gobject-introspection of marking gpointers as (nullable). See
https://bugzilla.gnome.org/show_bug.cgi?id=729660.
This includes adding some stub documentation comments for the
assertion macro error functions, which weren’t previously documented.
The new comments are purely to allow for annotations, and hence are
marked as (skip) to prevent the symbols appearing in the GIR file.
https://bugzilla.gnome.org/show_bug.cgi?id=719966
Now that we initialize the quark tables from a constructor,
reloading libglib is just as bad as reloading libgobject,
so add the linker option to the LDFLAGS for all our libraries.
https://bugzilla.gnome.org/show_bug.cgi?id=755609
It seems that VS 2015 optimizes out the constructor on windows,
so it is better to use a DllMain to initialize the library
and keep using a normal constructor on the other platforms.
This research was done by Arnav Singh.
https://bugzilla.gnome.org/show_bug.cgi?id=752837
If --prefix is specified, marshaller_prefix is allocated and never
freed. It does not actually have to be allocated — just use the static
string from argv.
Coverity CID: 1325370
This reverts commit 8e362161d9.
There is a fundamental difference between g_value_peek_pointer() and
g_value_get_pointer(), and it's not just complexity: the latter checks
if the GValue holds a pointer type, whereas the former doesn't.
https://bugzilla.gnome.org/show_bug.cgi?id=755922
g_value_unset() only works with initialized value and will assert
if the GValue is zero-filled (or initialized with G_VALUE_INIT). Document
this behaviour and refer to g_value_clear() for a method that work on
both initialized and zero-filled GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
This change allow leaving a scope before g_value_init() has been
called. This would happen if you do:
{
g_auto(GValue) value = G_VALUE_INIT;
}
Or have a return statement (due to failure) before the part of
your code where you set this GValue.
https://bugzilla.gnome.org/show_bug.cgi?id=755766
This will not catch the case where we fail in libffi and always use 0.
In fact, be a real annoying person and use (1 << 31) as a flags value to
test signedness, too.
Also update the testcase to actually use flags everywhere and ot uint.
https://bugzilla.gnome.org/show_bug.cgi?id=754882
Keeping these enabled causes too many people to file
bugs against gobject, and not enough people to send
patches to port away from deprecated properties.
This is almost always what you want, because if you're using this you
want to know if any "custom code" (i.e. not the default class closure)
is going to be run if you emit this signal.
I looked at all the existing uses of this and they were all broken in the
presence of g_signal_override_class_closure().
https://bugzilla.gnome.org/show_bug.cgi?id=754986
