It's necessary sometimes for installed tests to be able to run with a
custom environment. For example, the gsocketclient-slow test requires an
LD_PRELOADed library to provide a slow connect() (this is to be added in
a followup commit).
Introduce a variable `@env@` into the installed test template, which we
can override as necessary when generating `.test` files, to run tests
prefixed with `/usr/bin/env <LIST OF VARIABLES>`.
As the only test that requires this currently lives in `gio/tests/`, we
are only hooking this up for that directory right now. If other tests in
future require this treatment, then the support can be extended at that
point.
I'm trying to use `-fsanitize=thread` for OSTree, and some of
these issues seem to go into GLib. Also, the sanitizers work better if
the userspace libraries are built with them too.
This fix is similar to
b6814bb37c
Mixing atomic and non-atomic reads trips TSAN, so let's change the
assertions to operate on the local values returned from atomic
read/writes.
Without this change I couldn't even *build* GLib with TSAN, since we
use gresources during compilation, which uses GSubprocess, which hits
this code.
(Minor review fixes made by Philip Withnall <withnall@endlessm.com>.)
https://gitlab.gnome.org/GNOME/glib/issues/1224
This is an analogous commit to c1f5e528. The original fix only touched
gtype.h and not gtypemodule.h.
The *_init() functions have prototypes incompatible with *InitFunc types they
are being cast to. This upsets GCC 8's -Wcast-function-type that's enabled by
default with -Wextra.
Let's not have the public header files emit a warning and neutralize it by
doing a void(*)(void) cast first.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1666
So long, and thanks for everything. We’re a Meson-only shop now.
glib-2-58 will remain the last stable GLib release series which is
buildable using autotools.
We continue to install autoconf macros for autotools-using projects
which depend on GLib; they are stable API.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
And mention why it’s not a GInterfaceInitFunc as people who have read
the GObject docs cover-to-cover might expect.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Note that it's not reported with gcc. It's only reported with g++.
C++ code to reproduce this warning:
#include <glib-object.h>
G_BEGIN_DECLS
#define GARROW_TYPE_FILE (garrow_file_get_type())
G_DECLARE_INTERFACE(GArrowFile,
garrow_file,
GARROW,
FILE,
GObject)
struct _GArrowFileInterface {
GTypeInterface g_iface;
};
G_DEFINE_INTERFACE(GArrowFile,
garrow_file,
G_TYPE_OBJECT)
static void
garrow_file_default_init(GArrowFileInterface *iface)
{
}
G_END_DECLS
Build command line:
% g++ -Wall -shared -o liba.so a.cpp $(pkg-config --cflags --libs gobject-2.0)
Message:
In file included from /tmp/local.glib/include/glib-2.0/gobject/gobject.h:24,
from /tmp/local.glib/include/glib-2.0/gobject/gbinding.h:29,
from /tmp/local.glib/include/glib-2.0/glib-object.h:23,
from a.cpp:1:
a.cpp: In function 'GType garrow_file_get_type()':
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:219:50: warning: '<<' in boolean context, did you mean '<' ? [-Wint-in-bool-context]
#define G_TYPE_MAKE_FUNDAMENTAL(x) ((GType) ((x) << G_TYPE_FUNDAMENTAL_SHIFT))
~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:2026:11: note: in definition of macro '_G_DEFINE_INTERFACE_EXTENDED_BEGIN'
if (TYPE_PREREQ) \
^~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:1758:47: note: in expansion of macro 'G_DEFINE_INTERFACE_WITH_CODE'
#define G_DEFINE_INTERFACE(TN, t_n, T_P) G_DEFINE_INTERFACE_WITH_CODE(TN, t_n, T_P, ;)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
a.cpp:16:1: note: in expansion of macro 'G_DEFINE_INTERFACE'
G_DEFINE_INTERFACE(GArrowFile,
^~~~~~~~~~~~~~~~~~
/tmp/local.glib/include/glib-2.0/gobject/gtype.h:178:25: note: in expansion of macro 'G_TYPE_MAKE_FUNDAMENTAL'
#define G_TYPE_OBJECT G_TYPE_MAKE_FUNDAMENTAL (20)
^~~~~~~~~~~~~~~~~~~~~~~
a.cpp:18:20: note: in expansion of macro 'G_TYPE_OBJECT'
G_TYPE_OBJECT)
^~~~~~~~~~~~~
Conceptually the binding is kept alive as long as both the source and
target exist. This means that an API user needs to take some care to
either hold a reference or only use a pointer to the binding as long as
also holding references to both objects.
Clarify the documentation a bit.
Turns out the fix in commit 93555577c wasn't enough, when using glib as
subproject and the parent project uses only libgio_dep, and include
<gi18n.h>, it won't find libintl.h because it's in the
include_directories of libglib_dep. Fix that by declaring dependencies
explicitly, which is the right thing to do since glib and gobject are
public dependencies of gio. That reflects what we do for the pkg-config
file as well.
When passing a function to G_IMPLEMENT_INTERFACE, it actually has to
take two arguments. Who knew?
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When using glib as subproject we are forced to pass glib_dep,
gobject_dep and gio_dep to any build target. If we pass only gio_dep it
will missing include directory for glib and gobject.
Add tests using an object declared with G_DECLARE_FINAL_TYPE, that is derived
from another, declared using G_DECLARE_DERIVABLE_TYPE, and that
thus uses _GLIB_DEFINE_AUTOPTR_CHAINUP to define cleanup functions.
And verify that both g_autoptr(Type) and g_auto(s)list(Type) work
Fedora is using https://fedoraproject.org/wiki/Changes/Annobin
to try to ensure that all objects are built with hardening flags.
Pass down `CFLAGS` to ensure the SystemTap objects use them.
An assertion is harder to skip over, and using a g_critical() can give
us a more informative error message.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/179
This makes it easier to debug test failures, by ensuring that g_debug()
and g_test_message() are printed as TAP diagnostics.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1528
Signed-off-by: Simon McVittie <smcv@collabora.com>
g_object_bind_property() (transfer none) returns a GBinding with an existing internal
reference which is active as long as the "binding" is. This allows to optionally use
the binding without any memory management, as it will remove itself when it is no longer
needed.
There are currently three ways to remove the "binding" and as a result the reference:
1) Either the source or target dies and we get notified by a weakref callback
2) The user unrefs the binding until it is destroyed (which is semi-legal,
but worked and is used in the test suite)
3) The user calls g_binding_unbind()
In case (3) the problem was that it always calls unref even if the "binding" is already
gone, leading to crashes when called from bindings multiple times.
In #1373 and !197 it was noticed that a function always unrefs which would be a
"transfer full" annotation, but the problem here is that it should only remove the
ref when removing the "binding" and the annotation should stay "transfer none".
As a side effect of this fix it is now also possible to call g_binding_unbind() multiple
times where every call after the first is a no-op.
This also adds explicit tests for case (1) and (3) - only case (3) is affected by this change.
Part of runMkenumsWithHeader() was duplicated in test_reproducible(),
and would otherwise need to be duplicated again in upcoming tests. Many
places duplicated decoding stdout/stderr and checking the exit code.
Introduce a named tuple for the returned fields; and factor out writing
a template file to pass with --template.
The new python module, added with 0.46, works with Python 2 and 3 and
allows to pass a path for the interpreter to use, if the need arises.
Previously the meson build set PYTHON, used in the shebang line of
the scripts installed by glib, to the full path of the interpreter.
The new meson module doesn't expose that atm, but we should set it to
a executable name anyway, and not a full path.
Several of our tools are installed and are used by other projects to
generate code. However, there is no 'install' when projects use glib
as a subproject.
We need some way for glib to 'provide' these tools so that when some
project uses glib as a subproject, find_program('glib-mkenums') will
transparently return the glib-mkenums we just built.
Starting from Meson 0.46, this can be done with the
`meson.override_find_program()` function.
As a bonus, the Meson GNOME module will also use these
'overriden'/'provided' programs instead of looking for them in PATH.
