Some (broken) toolchains for example trip up
-Werror=missing-prototypes in system headers. This patch allows
people to skip the formerly hardcoded "baseline" warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=694757
The documentation was suggesting that using G_APPLICATION_IS_SERVICE
would automatically set an inactivity timeout (ie: app stays around for
a while after the use count drops to zero).
In reality, it only adds an initial 10 second wait for the first
activation message to arrive after which it uses the normal inactivity
timeout mechanism.
Implement the g_network_monitor_can_reach_async() rather than falling
back to the default implementation, which calls the sync version (not
in a thread).
https://bugzilla.gnome.org/show_bug.cgi?id=694181
Enumerate the GSocketConnectable before checking for a default route.
For some connectable types this will involve a DNS lookup. This will
elminate false positives for hosts behind a VPN since DNS lookup will
fail if the VPN is not connected.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If the resolver reloads (ie, if /etc/resolv.conf changes),
GNetworkAddress needs to re-resolve its addresses the next time it's
enumerated. Otherwise hosts that have different IP addresses inside
and outside a VPN won't work correctly if you hold on to a
GNetworkAddress for them for a long time.
https://bugzilla.gnome.org/show_bug.cgi?id=694181
If a GNetworkAddress is created with a hostname like "fe80::xxx%em1",
make sure that the scope_id corresponding to "em1" is present in the
GSocketAddresses it returns when used as a GSocketConnectable.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
Add GSimpleProxyResolver, for letting people do static proxy
resolution, and to use as a base class for other resolvers (such as
GProxyResolverGnome).
https://bugzilla.gnome.org/show_bug.cgi?id=691105
Add a proxy-resolver property to GSocketClient, to allow overriding
proxy resolution in situations where you need to force a particular
proxy rather than using the system defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=691105
This is a GLib reimplementation of dbus_address_escape_value().
It's useful if you want to construct a D-Bus address from pieces:
for instance, if you have a listening Unix socket whose path is known,
and you want to connect a D-Bus peer to it.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=693673
Reviewed-by: Colin Walters <walters@verbum.org>
[amended to add Since: 2.36 as per review]
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
If we don't connect to the control proxy's 'g-signal' signal, we won't have
'object-added' or 'object-removed' signals. So, connect to the 'g-signal' not
only when there already is a name-owner, but always.
https://bugzilla.gnome.org/show_bug.cgi?id=693285
While compiling, libtool will say that undefined symbols are not allowed, and
will refuse to make you a dll. This is only one line, easy to miss. And it
doesn't prevent `make' from completing successfully.
The code this patch adds is from other Makefile.am files that use
$(no_undefined). It's absence in gio is, most likely, an oversight.
Fixes#692058
The flowinfo and scope_id fields of struct sockaddr_in6 are in host
byte order, but the code previously assumed they were in network byte
order. Fix that.
This is an ABI-breaking change (since before you would have had to use
g_ntohl() and g_htonl() with them to get the correct values, and now
that would give the wrong values), but the previous behavior was
clearly wrong, and no one ever reported it, so it is likely that no
one was actually using it.
https://bugzilla.gnome.org/show_bug.cgi?id=684404
There are two benefits to this:
1) We can centralize any operating system specific knowledge of
close-vs-EINTR handling. For example, while on Linux we should never
retry, if someone cared enough later about HP-UX, they could come by
and change this one spot.
2) For places that do care about the return value and want to provide
the caller with a GError, this function makes it convenient to do so.
Note that gspawn.c had an incorrect EINTR loop-retry around close().
https://bugzilla.gnome.org/show_bug.cgi?id=682819
Ok, this function was just an awful mess before. Now the problem
domain is not trivial, and I won't claim this new code is *beautiful*,
but it should fix the bug at hand, and be somewhat less prone to
failure for the next person who tries to modify it. There's only one
unref call for each object now.
https://bugzilla.gnome.org/show_bug.cgi?id=692408
gio's glib-mkenums call needs to get gnetworking.h out of $(builddir),
not $(srcdir). Fix/simplify it by using $(filter) on $^ and letting
make find everything.
Also add -Wno-portability to AM_INIT_AUTOMAKE in configure.ac, so that
it doesn't warn about this (or about the gmake-specific features we
were already using in gio/tests/)
https://bugzilla.gnome.org/show_bug.cgi?id=691866
Use the same code GSocket does, to try SOCK_CLOEXEC first, and then
fall back to FD_CLOEXEC if it fails. (And fix that code to not call
fcntl if SOCK_CLOEXEC worked.)
https://bugzilla.gnome.org/show_bug.cgi?id=692332
When an error occurs while reading the file input stream in
g_file_load_contents (e.g. because the operation was cancelled), the
code is correctly calling g_task_return_error(), but in the callback
from the close operation, g_task_return_boolean() will be called again.
Code that cleans up its state in the async callback will then be called
twice, leading to invalid memory access.
https://bugzilla.gnome.org/show_bug.cgi?id=692202
Declare explicit support for monitor NFS from the fam file monitoring
backend. This will cause it to be preferred for monitoring on NFS, if
it is installed.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Add a pair of new extension points: 'gio-nfs-file-monitor' and
'gio-nfs-directory-monitor'.
Add a check to GLocalFile when creating a file monitor. If the
requested file is in the user's home directory and the user has an NFS
home directory then attempt to use an implementation of one of the new
extension points. If we don't have any implementations then fall back
to the normal "local" monitors.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
Get rid of the complicated default module detection code in
GLocalFileMonitor and GLocalDirectoryMonitor and use the new
_gio_module_get_default_type() function instead.
This change also adds the ability to override the default file monitor
via the GIO_USE_FILE_MONITOR environment variable in the same way as can
be done for GIO_USE_VFS.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
_gio_module_get_default() is a very convenient function for modules
implementing a singleton -- it finds the default module by priority
subject to override by a given environment variable name, instantiates
it, and caches the instance for future calls. It also has the ability
to query instances for being 'active' using a callback.
It doesn't work very well for non-singletons (like file monitors).
Add a new function _gio_module_get_default_type() that skips the
instantiation, returning the GType instead. As a replacement for the
'active' callback, a vtable offset can be given for a virtual function
to use to query if a particular backend is supported.
https://bugzilla.gnome.org/show_bug.cgi?id=592211
We have various sub directories in glib/ and gio/ (eg: inotify, gnulib,
pcre, xdgmime, etc.) that build convenience libraries that are then
included into libglib and libgio. The files in these directories need
to be built with the same visibility policy as the files in the first
level directories, so add CFLAGS for them all.
This wasn't a problem when the visibility flags were set directly in
CFLAGS but then we had to deal with some modules that we built that we
explicitly wanted to export symbols from.
For now, we can keep things the way they are because it's less hacky and
although it's a theoretical hazard to forget these CFLAGS, we rarely add
new subdirectories to the build.
Before this commit, the only difference between the expected and actual
ABI were the addition of _init and _fini symbols in each module (now
that regexp-based export control is not catching those).
Add read_async() and skip_async() tests to buffered-input-stream.
Fix and re-enable filter-streams's existing close_async() tests, and
add read_async(), skip_async(), and write_async() tests as well. Also,
redo the tests to use dummy GFilterInputStream and GFilterOutputStream
subclasses rather than GBufferedInput/OutputStream, so that we're
testing the base filter stream implementations of everything (since
the buffered stream overrides are already getting tested in the
buffered-input-stream and buffered-output-stream tests anyway).
Add a skip_async() test to unix-streams. (This one would crash without
the bugfix in the previous commit.)
skip_callback_wrapper expect the user_data (callback_data)
to be the task holding the task_data, not the task_data
itself.
Otherwise the task_data is cast as GTask and then task_data
is extracted from this bogus task.
https://bugzilla.gnome.org/show_bug.cgi?id=691812
We only want to control the default visibility for our five main
installable libraries: libglib, libgthread, libgmodule, libgobject,
libgio. We should therefore only set -fvisibility=hidden when building
those.
Use a separate substitution variable for this purpose.
Using CFLAGS directly leads to some modules built in testcases not
exporting their symbols (and then the tests fail). It also affects the
fam file monitoring module.
Colin had originally done it this way in his visibility patch series but
I failed to understand why so I didn't copy it. Now I do.
Also: revert changes made to two testcases in an attempt to work around
this issue.
https://bugzilla.gnome.org/show_bug.cgi?id=691756
Add an #ifdef G_OS_UNIX around the GLIB_AVAILABLE_IN_ALL annotation on
the _get_type() functions for GLocal{File,Directory}Monitor.
These symbols are in private header files and are only exported so that
the in-tree file monitoring modules can subclass. This is only needed
on UNIX and was therefore never part of the public ABI on Windows.
Caught by Dieter Verfaillie.
One of our testcases builds a small giomodule for testing the loading of
modules containing resources. Unfortunately, this module gets built
using the same CFLAGS as the rest of GLib, including the visibility
flags (defaulting to hidden).
Use "config.h" to get a declaration of _GLIB_EXTERN that will export
symbols properly and use it to annotate the necessary APIs.
The kqueue file monitoring backend was misusing G_GNUC_INTERNAL for want
of 'static' in a couple of places and also using it to declare a lock
that was never used at all.
Fix those up.
With visibility now under the control of __declspec(dllexport) we no
longer need to build .def files or use them for building our various
.dll files.
.def files used to be installed (even though it is only really useful
when creating the .dll or .lib file). Don't do that anymore either.
The Makefiles still contain rules to create a .lib file for use with
Visual Studio and these rules require .def files. There are special
requirements to using these rules (like having installed and setup
Microsoft tools for use during the build) and therefore the problem of
creating a .def file for use with them is left open to anyone willing to
make the effort. Many options are available depending on which
toolchain is in use (dlltool, pexport, gendef, dumpbin.exe, just to name
a few).
If we can find a free tool for creating .lib files in the future, we
should probably revisit this issue and add proper support back to our
build system.
Add the GLIB_AVAILABLE_IN_ALL annotation to all old functions (that
haven't already been annotated with the GLIB_AVAILABLE_IN_* macros or a
deprecation macro).
If we discover in the future that we cannot use only one macro on
Windows, it will be an easy sed patch to fix that.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
glib-mkenums is not currently clever enough to know which version an
enum type was added in, so just mark all the _get_type() functions as
available in all versions.
https://bugzilla.gnome.org/show_bug.cgi?id=688681
This allows compilation with clang without errors, even when
-Wformat-nonliteral is active (as long as there are no real cases of
non literal formatting).
https://bugzilla.gnome.org/show_bug.cgi?id=691608
g_input_stream_real_skip_async() wants to use read_async() normally,
but will use skip() in a thread instead if it sees that read_async()
will end up using threads. Except that the test for "will read_async()
use threads" never got updated to know about the GPollableInputStream
support in read_async(), so it was doing the wrong thing in that case.
Fix.
Also remove a small bit of pre-GTask cruft noticed nearby.
https://bugzilla.gnome.org/show_bug.cgi?id=691489
For OSTree, I use Gio and also really care about performance. It's
disturbing to see open('.hidden') all over my straces and such. At
the moment I have an explicit set of things to query, as opposed to
"standard::*", since even before this that also implies an lstat() of
the parent directory.
This matches up with what we do for all the other attributes.
See https://bugzilla.gnome.org/show_bug.cgi?id=587806https://bugzilla.gnome.org/show_bug.cgi?id=691558
Since we're dynamically loading objects, after the g_type_init()
change, we now need to ensure people building with --as-needed don't
lose the DT_NEEDED on libgobject.
https://bugzilla.gnome.org/show_bug.cgi?id=691077
Some OS (e.g. OpenBSD) do not implement IP v4-mapped addresses. When
this is the case, then we get a "Connection refused", so force the test
to pass to that further tests can run.
https://bugzilla.gnome.org/show_bug.cgi?id=686058
The attached patch adds support for the btrfs "clone" ioctl which
makes Copy-on-Write reflinks, resulting in cheap O(1) copies when
source/destination are on the same filesystem. The ioctl itself is
quite straightforward, and GNU coreutils has had support since 7.5
(--reflink=auto --sparse=auto).
The ioctl only operates on regular files and symlinks, and always
follows symlinks; checks have been added accordingly.
This patch would be very useful for everyone who uses btrfs
filesystems (Meego folks for instance). On systems that don't have
btrfs, or if the the source is not on a btrfs filesystem, the ioctl
returns EINVAL, and the fallback code is triggered. Hence this will
cause no problems for non-btrfs users.
https://bugzilla.gnome.org/show_bug.cgi?id=626497
a5876e5f made GMemoryInputStream subclassable, but accidentally broke
read_async() and skip_async() in the process. The immediately
following e7983495 fixed read_async() (and added a test for it), but
skip_async() accidentally got... skipped.
Fix it now and add a test for it.
Also, GMemoryInputStream's skip_async() was assuming that skip() could
never fail, which is true of its own implementation, but might not be
true of a subclass's, so do proper GError handling too.
This will let us drop the dbus-python dependency.
The C version does not 100% reproduce all the hash table
and array manipulation of the python version, but the tests
do not rely on it anyway.
This greatly simplifies the test since everything is now in a single
process and possible bugs / quirks in libdbus-1 will not interfere
with the tests. On the other hand, we no longer test interoperability
with libdbus-1. This is somewhat moot, however, since other tests that
involve a message bus (e.g. GTestDBus users which include most of the
GDBus test suite itself) will test this.
Also ensure that we don't pollute existing D-Bus keyrings for the
DBUS_COOKIE_SHA1 authentication method (e.g. files in the
~/.dbus-keyrings directory) by setting the environment variables
G_DBUS_COOKIE_SHA1_KEYRING_DIR and
G_DBUS_COOKIE_SHA1_KEYRING_DIR_IGNORE_PERMISSION.
All in all, this change avoids some thorny issues where the GDBus and
libdbus-1 implementations disagree on whether an item in the D-Bus
keyring is still valid (items have an age etc.). In reality, since the
DBUS_COOKIE_SHA1 authentication method is never used in production,
this is never hit in production. This bug was, however, frequently hit
if you just ran the test suite repeatedly for 15 minutes or so.
Also add TODO items to mention that we currently don't test corner
cases involving
- DBUS_COOKIE_SHA1 timeouts
- libdbus-1 interoperability
Signed-off-by: David Zeuthen <zeuthen@gmail.com>
This DTD wasn't syntactically correct, and didn't actually
describe keys correctly. This change makes it a bit too lax,
but at least it can be used now.
https://bugzilla.gnome.org/show_bug.cgi?id=690538
This returns a GInputStream corresponding to the stdin on the
commandline that caused this invocation.
The local case works on both UNIX (GUnixInputStream on stdin) and
Windows (GWin32InputStream on GetStdHandle(STD_INPUT_HANDLE)). The
remote case works only on UNIX (by fd passing over D-Bus).
https://bugzilla.gnome.org/show_bug.cgi?id=668210
