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
Add a new GFileMonitorFlag: G_FILE_MONITOR_WATCH_HARD_LINKS. When set,
changes made to the file via another hard link will be detected.
Implement the new flag for the inotify backend.
https://bugzilla.gnome.org/show_bug.cgi?id=532815
As RFC 2292 points out, some platforms (e.g. Darwin 9.8.0) provide
CMSG_FIRSTHDR(msg) which just returns msg.msg_control without first
checking if msg.msg_controllen is non-zero. We need a workaround for
such platforms not to let g_socket_receive_message() segfault.
https://bugzilla.gnome.org/show_bug.cgi?id=690388
If tasks block waiting for other tasks to complete then the system can
end up starved for threads. Avoid this by bumping up max-threads in
that case.
This also reverts 7b1f8c58 and reverts max-threads for GTask's
GThreadPool back to 10.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
On IPv6 sockets, set both the IPv4 and IPv6 versions of IP socket
options, in case the socket is (or might become) IPv4-wrapped. (But
ignore errors when setting the IPv4 version.)
Similarly, when joining or leaving a multicast group, pick the sockopt
to use based on the address family of the multicast address rather
than the address family of the socket.
https://bugzilla.gnome.org/show_bug.cgi?id=687092
Since Windows builds by Visual C++ do not make use of autotools during
its build process, we need to dist a pre-configured
gio/gnetworking.h(.win32) for such builds.
The vs9/vs10 (and therefore vs11) property sheets are updated as well
https://bugzilla.gnome.org/show_bug.cgi?id=690163
This is a new convenience method designed to simplify some use
cases of GFileEnumerator, by making it easy to get the next file
from a file enumerator.
https://bugzilla.gnome.org/show_bug.cgi?id=690083
Add g_socket_get_option() and g_socket_set_option(), wrapping
getsockopt/setsockopt for the case of integer-valued options. Update
code to use these instead of the underlying calls.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Install a public "gnetworking.h" header that can be used to include
the relevant OS-dependent networking headers. This does not really
abstract away unix-vs-windows however; error codes, in particular,
are incompatible.
gnetworkingprivate.h now contains just a few internal URI-related
functions
Also add a g_networking_init() function to gnetworking.h, which can be
used to explicitly initialize OS-level networking, rather than having
that happen as a side-effect of registering GInetAddress.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
Since there is only one resolver implementation now, we can move the
resolver utility functions from gresolver.c into gthreadedresolver.c,
and remove the prototypes from gnetworkingprivate.h.
https://bugzilla.gnome.org/show_bug.cgi?id=623187
The G_OBJECT_WARN_INVALID_PROPERTY_ID() macro uses a local variable
named "_object"; work around this by using "object" as the variable we
pass in.
https://bugzilla.gnome.org/show_bug.cgi?id=689377
This makes sure not to ifdef _g_io_win32_get_module() out when glib is
built as a static lib, and also fixes it to work when DllMain isn't
available.
The implementation uses GetModuleHandleEx() which is only available on
Windows XP and later, so this commit effectively drops the Windows 2000
support in glib. Earlier commit 731b4699 already took care of defining
_WIN32_WINNT to support the Windows XP API.
https://bugzilla.gnome.org/show_bug.cgi?id=675516
Now that we're directly accessing the memory holding a message blob,
we can access strings directly while reading them. This speeds up
read_string significantly, since we no longer malloc/memcpy/free.
The three processes this test creates need to be executed
in order, and g_usleep was used to guarantee that.
However, under heavy load, that is not enough. Instead,
wait until the children start by making sure they have
written to stdout before proceeding any further.
https://bugzilla.gnome.org/show_bug.cgi?id=664627
GData*Streams incur significant overhead, and we do not need all of the
functionality that they provide, since we only ever read from/write to
memory when handling message blobs, so it is more performant to use a
simple structure.
https://bugzilla.gnome.org/show_bug.cgi?id=652650
... and g_content_type_get_generic_icon_name(). The new functions are
implemented for Win32 since commit dace477c, so we no longer need to
guard them with G_OS_UNIX.
Really, the memory output stream API is too warped around the model
where it's a fixed size buffer that you've already allocated. Even in
C, I find myself always wanting to use it to just accumulate data into
an arbitrary-sized buffer it allocates.
Unfortunately, it's also not usable from bindings because it's not
common to bind g_free() and g_realloc(), but if you just pass NULL, you
get the default of a fixed size, which is useless as per above.
I am going to use this from a gjs test case, and the GSubprocess test
cases also will use it.
https://bugzilla.gnome.org/show_bug.cgi?id=688931
Add a pair of new APIs: one to GFile to create a new file from a
commandline arg relative to a given cwd and one to
GApplicationCommandLine to create a GFile from an arg, relative to the
cwd of the invoking commandline.
https://bugzilla.gnome.org/show_bug.cgi?id=689037
If we fail to start (and don't register() or call startup()) then also
don't call shutdown(). This happens in the case of failing to parse
commandline arguments, for example.
gnome-session needs to know the startup id that was given to
a started app; this was not available via GAppLaunchContext.
This commit adds a ::launched signal to get this information.
At the same time, turn the launch_failed vfunc into a signal
as well.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
gnome-session still uses EggDesktopFile, since GDesktopAppInfo is
missing a handful of APIs that are needed to implement the
autostart spec. This patch adds the minimum that is required.
https://bugzilla.gnome.org/show_bug.cgi?id=688497
This reverts commit 85976cf91d and
properly removes the offending symbols from gio.symbols.
These two private symbols were found to be exported during Colin's
recent work cleaning up function visibility (among other things).
They were never exposed in any header file and I am 100% certain that
they have never been used by anybody. They were always private -- only
exposed on the library symbol list.
This change will cause ABI checking tools to complain that we have
removed functions, but the change is completely harmless for actual
applications.
https://bugzilla.gnome.org/show_bug.cgi?id=687441
MacOS provides the O_EVTONLY flag to open(2) which allow to open a file
for monitoring without preventing an unmount of the volume that contains
it.
https://bugzilla.gnome.org/show_bug.cgi?id=688518
Re-#define a few socket functions to work around winsock's prototypes
having, eg, "int *" rather than "unsigned int *", or "char *" rather
than "void *".
(Also fix two places that mistakenly assumed guint==guint32.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
GLocalFile was (in certain situations) translating a path like
"/foo/bar/baz" to "/foo\bar\baz" on win32. Fix it to make sure the
initial directory separator gets canonicalized too.
Fixes gio/tests/g-icon on win32.
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Rather than defining _WIN32_WINNT only in a handful of files, define
it in config.h, like we do with _GNU_SOURCE.
(Also remove a "#define WIN32_LEAN_AND_MEAN" that isn't really all
that useful.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Rather than using "extern" declarations of these win32 functions
everywhere they're needed, just prototype them in glib-private.h.
(Which also fixes the fact that they weren't prototyped in the files
where they're defined.)
https://bugzilla.gnome.org/show_bug.cgi?id=688109
Written by Dmitry Matveev as part of GSoC 2011:
http://netbsd-soc.sourceforge.net/projects/kqueue4gio/
This brings native file monitoring support on systems supporting kqueue(3)
(all BSDs) and remove the need to rely on the unmaintained gamin software.
The backend adds GKqueueDirectoryMonitor and GKqueueFileMonitor.
Some parts rewritten by myself (to prevent needing a configuration file).
Helpful inputs from Colin Walters and Simon McVittie.
https://bugzilla.gnome.org/show_bug.cgi?id=679793
$ sed -i s,determing,determining,g gio/gdrive.c
$ sed -i s,determing,determining,g gio/gdbusprivate.c
http://www.merriam-webster.com/dictionary/determining
For some reason according to `git log --follow` the whole file was created during some translation update.
commit c45b813504
Author: Timo Jyrinki <timo@debian.org>
Date: Mon Mar 12 11:02:04 2012 +0200
Finnish translation update from http://l10n.laxstrom.name/wiki/Gnome_3.4 translation sprint
Darwin's poll doesn't change revents if there are no available events, though it returns 0. Initialize the fd.revents to 0 so that the test passes.
That reveals a test failure, though, because with socket streams it takes time for an event to pass through the socket. Provide an 80-usec delay to allow time for the propagation.
We were passing the wrong destroy notify when returning the list of
records, so it would crash if it got called (ie, if you didn't call
g_resolver_lookup_records_finish()).
(Also fix s/targets/records/ throughout the records functions.)
These both existed in 2.34.1, but are not exposed in headers, and were
meant to be private. Making them static (in commit 84475e43) was
technically an ABI break, and in particular it causes abicheck.sh to fail.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=687441
Reviewed-by: Colin Walters <walters@verbum.org>
Even private functions that are actually called across compilation
units should have prototypes. For g_dbus_action_group_sync(), create
one in gdbusactiongroup-private.h
https://bugzilla.gnome.org/show_bug.cgi?id=687385
Add some extra protection when 'preparing' a group that doesn't yet
contain any menus. This can happen if you subscribe to a group that
doesn't yet exist.
It was possible to crash any application using
g_dbus_connection_export_menu_model() by requesting a non-existent
subscription group over the bus.
In practice this only happened in races -- where the proxy sees a group
that exists and queries it, but by the time it does, it's already gone.
https://bugzilla.gnome.org/show_bug.cgi?id=687089
Allow GDBusObjectManagerClient to work on peer to peer DBus
connections. Don't require that a unique bus name is available
for the object manager, if the owned bus name is NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=686920
When building the file attribute table info for local files, use
thumbnail paths in $XDG_CACHE_DIR/thumbnails/large in addition to
$XDG_CACHE_DIR/thumbnails/normal.
Failing to do this would cause an application that creates large
thumbnails by default to never find any value for
G_FILE_ATTRIBUTE_THUMBNAIL_PATH, with no
G_FILE_ATTRIBUTE_THUMBNAILING_FAILED set, which might cause the
application to either think thumbnailing is still in progress, or
blindly requeue thumbnail operations in a loop.
Large thumbnails are generally preferred, so we now default to the path
of a large thumbnail (in case both are present).
https://bugzilla.gnome.org/show_bug.cgi?id=686895
Sometimes the poll duration in the /socket/timed_wait test is slightly
bigger than the requested 100000, causing failures like:
GLib-GIO:ERROR:socket.c:620:test_timed_wait:
assertion failed (poll_duration < 110000): (110057 < 110000)
Adjust the test to allow some jitter in the "too high" direction.
https://bugzilla.gnome.org/show_bug.cgi?id=686458
GBusNameVanishedCallback is called with a NULL GDBusConnection in the
case that the connection has vanished. We were doing an assert to
verify that it was the same as we had exported the menu on and that
assert was failing.
https://bugzilla.gnome.org/show_bug.cgi?id=685995
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
We were using the user-passed value of the @property argument for
several purposes in g_settings_bind(): error messages, binding
uniqueness (ie: one-binding-per-property-per-object) and most
importantly, connecting to the detailed notify:: signal.
The user may pass a string like "property_name" when the property's
canonical name is "property-name". g_object_class_find_property() will
find the property under these circumstances, but a connection to
"notify::property_name" will not notice notifies emitted for
"property-name".
We can solve this by using the user's string to perform the lookup and
then using pspec->name for everything after that.
https://bugzilla.gnome.org/show_bug.cgi?id=684882
