meson in git master now warns about a missing `check:` kwarg, and may
eventually change the default from false to true.
Take the opportunity to require `objcopy --help` to succeed -- it is
unlikely to fail, but if it does something insane happened.
Relax the requirement for the test to only be compiled/run under gcc,
since a version of LLVM was released which supports `--add-symbol`.
`objcopy` should be overrideable to be `llvm-objcopy` by using a machine
file as per https://mesonbuild.com/Machine-files.html#binaries.
Suggested and tested by Grigory Vasilyev.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2423
Calling `dlopen()` with `libutil.so` makes the installed tests depend on
having glibc's development files installed. To avoid this, we can work
out the runtime library name at build time and `dlopen` that instead.
This approach is [taken from libfprint][1], thanks to Marco Trevisan.
[1]: f401f399a8
AddressSanitizer, UndefinedBehaviourSanitizer and probably others
involve adding instrumentation into the code under test, which doesn't
go well with LD_PRELOAD modules that absolutely need to be
self-contained.
Signed-off-by: Simon McVittie <smcv@collabora.com>
- use watcher auto start flag.
- use watch_name_on_connection_with_closures.
- use an existing service name for auto start.
Closes#2011
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
* Add g_tls_connection_get_channel_binding_data API call
* Add g_dtls_connection_get_channel_binding_data API call
* Add get_binding_data method to GTlsConnection class
* Add get_binding_data method to GDtlsConnection interface
* Add GTlsChannelBindingType enum with tls-unique and
tls-server-end-point types
* Add GTlsChannelBindingError enum and G_TLS_CHANNEL_BINDING_ERROR
quark
* Add new API calls to documentation reference gio-sections-common
There are two memory monitor tests that use Python's unittest module directly,
but GLib tests should be outputting TAP. Use the embedded TAPTestRunner to
ensure that TAP is output for these tests too.
There were some problems about where to install `gio-launch-desktop` to
support multiarch systems without circular dependencies. Simon McVittie
suggested that, actually, given the current set of platforms supported
by `GDesktopAppInfo` (they’re all POSIX), we could just use `sh`.
That simplifies things nicely. `gio-launch-desktop` can always be
resurrected (and the multiarch debate continued and resolved) if needed
in future.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1633
This makes it consistent with the `GLIB_MIN_REQUIRED` defines which are
used for API stability/versioning in C code.
It doesn’t otherwise change the behaviour of the `--glib-min-version`
argument.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1993
1) When parsing the executable name out of the command line,
see if the executable is rundll32.exe. If that is the case,
use the DLL name from its first argument as the "executable"
(this is used only for matching, and Windows Registry matches
these programs by their DLLs, so this is correct; for running
the application GLib would still use the command line, with
rundll32).
2) If an app runs with rundll32, ensure that rundll32 arguments
can be safely quoted. Otherwise GLib will break them with its
protective quotation.
Currently the code generated by gdbus-codegen uses
G_DBUS_CALL_FLAGS_NONE in its D-Bus calls, which occur for each method
defined by the input XML, and for proxy_set_property functions. This
means that if the daemon which implements the methods checks for
G_DBUS_FLAGS_ALLOW_INTERACTIVE_AUTHORIZATION and only does interactive
authorization if that flag is present, users of the generated code have
no way to cause the daemon to use interactive authorization (e.g. polkit
dialogs).
If we simply changed the generated code to always use
G_DBUS_FLAGS_ALLOW_INTERACTIVE_AUTHORIZATION, its users would have no
way to disallow interactive authorization (except for manually calling
the D-Bus method themselves).
So instead, this commit adds a GDBusCallFlags argument to method call
functions. Since this is an API break which will require changes in
projects using gdbus-codegen code, the change is conditional on the
command line argument --glib-min-version having the value 2.64 or
higher.
The impetus for this change is that I'm changing accountsservice to
properly respect G_DBUS_FLAGS_ALLOW_INTERACTIVE_AUTHORIZATION, and
libaccountsservice uses generated code for D-Bus method calls. So
these changes will allow libaccountsservice to continue allowing
interactive authorization, and avoid breaking any users of it which
expect that. See
https://gitlab.freedesktop.org/accountsservice/accountsservice/merge_requests/46
It might make sense to also let GDBusCallFlags be specified for property
set operations, but that is not needed in the case of accountsservice,
and would require significant work and breaking API in multiple places.
Similarly, the generated code currently hard codes -1 as the timeout
value when calling g_dbus_proxy_call*(). Add a timeout_msec argument so
the user of the generated code can specify the timeout as well.
Also, test this new API. In gio/tests/codegen.py we test that the new
arguments are generated if and only of --glib-min-version is used with a
value greater than or equal to 2.64, and in gio/tests/meson.build we
test that the generated code with the new API can be linked against.
The test_unix_fd_list() test also needed modification to continue
working now that we're using gdbus-test-codegen.c with code generated
with --glib-min-version=2.64 in one test.
Finally, update the docs for gdbus-codegen to explain the effect of
using --glib-min-version 2.64, both from this commit and from
"gdbus-codegen: Emit GUnixFDLists if an arg has type `h` w/
min-version".
We can't use session_bus_down() in the test since gdocumentportal.c
holds a reference to the session bus connection, preventing it from
being finalised.
Those tests require Python, gobject-introspection and python-dbusmock
making them unsuitable to be run within the uninstalled test suite.
There are no restrictions of dependencies when it comes to installed
tests so use those to exercise GMemoryMonitor.
Add a Python-based test wrapper for the `gdbus-codegen` executable,
similar to the existing tests for `glib-mkenums` and friends.
Add a few basic tests to begin with, but this doesn’t approach anywhere
near full coverage.
The next step is to move the existing Meson-based `gdbus-codegen` tests
from `gio/tests/meson.build` into the Python test suite.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1612
Tools like this should be configurable in a cross or native file. In
particular, if we are cross-compiling (with an executable wrapper like
qemu-arm), the build system ld is not necessarily able to manipulate
host system objects.
Signed-off-by: Simon McVittie <smcv@collabora.com>
In particular, if libbdus is available, we test interoperability with
a libdbus client: see GNOME/glib#1831. Because that issue describes a
race condition, we do each test repeatedly to try to hit the failing
case.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Otherwise we’ll end up using the host’s `objcopy`, which will output
object files in the wrong format.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1916
Instead of letting each directory to find its way to link with libdl,
it is easier to put the check in the top level, so its result can be
used by all directories.
It is a follow-up of https://gitlab.gnome.org/GNOME/glib/merge_requests/810.
We're using the `install` argument for configure_file() all over the
place.
The support for an `install` argument for configure_file() was added in
Meson 0.50, but we haven't bumped the minimum version of Meson we
require, yet; which means we're getting compatibility warnings when
using recent versions of Meson, and undefined behaviour when using older
versions.
The configure_file() object defaults to `install: false`, unless an
install directory is used. This means that all instances of an `install`
argument with an explicit `true` or `false` value can be removed,
whereas all instances of `install` with a value determined from a
configuration option must be turned into an explicit conditional.
We need to enable building the dirent and gnulib sources for clang-cl,
as we are still using the Microsoft-style headers and lib's and CRT.
We need to also do this for the following, for similar reasoning:
-Symbol export (via __declspec(dllexport))
-Dependency discovery without pkg-config files
-long long and ssize_t detection
We do, however, enable the autoptr tests for clang-cl builds. Note that
at this point real MSVC builds are still better supported than clang-cl
builds, and it will likely remain so for at least the near future,
alhtough real MSVC builds of the GTK stack are consumable and are usable
by clang-cl.
The `monitor` test was originally written to test GFileMonitor with
directories. Over time, `testfilemonitor` acquired units for testing
directories as well, which made the `monitor` test reduntant.
Other GCC-like implementations of ld/objcopy (like LLVM) don’t yet
support the right command line arguments, so can’t compile the test.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1709
This introduces no functional changes, but combines two duplicated lists
and makes the meson.build file a little easier to follow.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1711
After repeated local testing, I can’t reproduce failures with them:
meson test --repeat 5000 gdbus-auth
meson test --repeat 5000 gdbus-bz627724
meson test --repeat 5000 gdbus-connection
The FreeBSD failures from pthread calls mentioned in #1614 should
probably manifest as use-after-free for GMutex or pthread_mutex_t on
Linux. Failing that, I haven’t seen any relevant FreeBSD failures on CI
for at least a month, so if it’s not fixed, the chances of debugging are
very low.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://gitlab.gnome.org/GNOME/glib/issues/1614
Check for RTLD_NEXT being present, and disable the gsocketclient-slow
test if it's absent, since the shlib dependency of that test requires
RTLD_NEXT to function.
This allows the testsuite to be built on Cygwin, which behaves
exactly like UNIX, but doesn't have RTLD_NEXT.
The test performs implicit autolaunching of a bus
and checks if it is connectible.
In build the test is moved from "only non-windows with have_dbus_daemon"
to "anywhere".
This is intentional: actually it doesn't execute any external
binaries on unix (so doesn't require dbus_daemon)
and now has win32 implementation.
The test has some problems that are not problems of test itself,
but are reasoned by current win32 implementation:
- since the implementation uses global win32 kernel objects
with fixed names not depending on g_get_user_runtime_dir or other context
if preexisting bus running by some other libgio-using application
the test would silently pass.
- since the implementation uses problematic time-based synchronization,
that has a race condition between opening and reading mmaped address,
the test may randomly fail (I'd not seen this in practice).
- since the implementation autolaunched process works for 3 seconds
after last client disconnects, the executed subprocess runs for 3 seconds
after test exit, maybe locking the libgio-2.0-0.dll file for that time.
