Various gio modules include gmodule.h that requires the
gmodule-visibility.h to be already built.
To make this easier, just provide a dependency and use it where we are
building modules that do not depend on libgio_dep (that already includes
that).
Fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2982
Building GLib 2.75.0 on Linux adds various inotify-related internal
symbols to the ABI, which doesn't seem to have been intentional.
I went through the other libraries in the build system, and it looks
as though the BSD kqueue backend would have the same problem.
GNU symbol visibility probably doesn't do anything for gio/win32, but
for completeness I've set that to use hidden symbols too, on the basis
that it'll be easier to get this right if we're consistent.
Resolves: https://gitlab.gnome.org/GNOME/glib/-/issues/2811
Signed-off-by: Simon McVittie <smcv@collabora.com>
It must only be defined when building libgio. This requires some
workaround to allow include of some gio private headers.
When GIO_COMPILATION is not defined we cannot include individual gio
headers. We workaround that by defining __GIO_GIO_H_INSIDE__ in some
places. Also gdbusprivate.h is not an installed header, so it's fine to
include it directly.
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some editors automatically remove trailing blank lines, or
automatically add a trailing newline to avoid having a trailing
non-blank line that is not terminated by a newline. To avoid unrelated
whitespace changes when users of such editors contribute to GLib,
let's pre-emptively normalize all files.
Unlike more intrusive whitespace normalization like removing trailing
whitespace from each line, this seems unlikely to cause significant
issues with cherry-picking changes to stable branches.
Implemented by:
find . -name '*.[ch]' -print0 | \
xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g'
Signed-off-by: Simon McVittie <smcv@collabora.com>
_kqsub_free assumes the caller has called _kqsub_cancel before calling
it. It checks if both 'deps' and 'fd' have been freed and aborts when
the condition is not met. Since the only caller of _kqsub_free is
g_kqueue_file_monitor_finalize, which does call _kqsub_cancel before
calling _kqsub_free, it seems to be correct for _kqsub_free to assert
values of these two members there.
However, it is possible for _kqsub_cancel to return early without
freeing any resource _kqsub_free expects to be freed. When the kevent
call fails, _kqsub_cancel does not free anything and _kqsub_free aborts
with assertion failure. This is an unexpected behavior, and it can be
fixed by always freeing resources in _kqsub_cancel.
Fixes: https://gitlab.gnome.org/GNOME/glib/issues/1935
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>
Previously, kqueue file monitor only add event sources for directories
regardless of the type of the file being monitored. Doing so may be
possible on inotify, but it is not sufficient on kqueue. Watching a
directory on kqueue doesn't report changes made to files under it, and
we must watch files themselves to get notified. This problem is fixed
by adding a second watch for non-directory file monitors, and the result
is that we are now able to receive 'CHANGED' and 'ATTRIBUTE_CHANGED'
events for non-directory files.
Since having two watches on one file monitor requires many code changes
to work properly, this commit also changes the following things:
- NOTE_ALL macro is now replaced by note_all inline function. Since the
kqueue backend is shared by all BSD operating systems, there are a
few difference between these systems. It is easier to do '#ifdef'
check in a function than in a macro.
- Both g_kqueue_file_monitor_callback and g_kqueue_file_monitor_cancel
now holds a lock before accessing kqueue_sub structs. This fixes a
crash when these two functions are called from different threads,
causing g_kqueue_file_monitor_callback to access freed memory.
- 'mask' variable in g_kqueue_file_monitor_callback is now removed.
The usage of 'mask' was wrong because of the 'mask > 0' check.
'CHANGED' event has value 0 so the 'mask > 0' check made it
impossible to emit 'CHANGED' events.
- kqueue-missing scans can now be triggered from the kqueue event
callback instead of always waiting for 4 seconds.
- Don't remove a file from kqueue on unlink unless its hard link count
has dropped to zero.
- Don't use 'else if' in the check of 'fflags'. It is possible for a
kevent to have multiple flags set.
- Don't use g_file_monitor_emit_event directly. Always use
g_file_monitor_source_handle_event to report events.
Events submitted to g_file_monitor_emit_event are delivered
immediately, but events sent to g_file_monitor_source_handle_event
are scheduled by GLocalFileMonitor. If we mix the two, the order of
events will be wrong and tests will fail.
- Report 'CHANGES_DONE_HINT' immediately after 'CREATED' if the file
created is not a regular file. This is copied from ih_event_callback.
The check in _ke_is_excluded, which causes GKqueueFileMonitor to
fallback to GPollFileMonitor when it returns TRUE, was made to prevent
file monitor from blocking unmount of removable drives on systems not
supporting O_EVTONLY flag in open. However, since g_mount_can_unmount
always returns TRUE on Unix-like platforms, the check always returns
TRUE on non-standard mount points, which is very likely to cause all
programs on the desktop to use the polling fallback if GNOME is
installed in a different prefix for development. This makes the desktop
sluggish and results in bad developer experience on *BSD.
gioenumtypes needs to be generated:
In file included from ../../../../external/glib/gio/kqueue/gkqueuefilemonitor.c:37:
In file included from ../../../../external/./glib/gio/glocalfilemonitor.h:25:
In file included from ../../../../external/./glib/gio/gunixmounts.h:24:
../../../../external/./glib/gio/gio.h:86:10: fatal error: 'gio/gioenumtypes.h' file not found
#include <gio/gioenumtypes.h>
^~~~~~~~~~~~~~~~~~~~
https://bugzilla.gnome.org/show_bug.cgi?id=794325
Removing the event and closing the related file descriptor must be
done first to make sure the kqueue subsystem delete pending events.
The timeout must be disarmed before freeing the directory dependency
list otherwise it might populate it again.
https://bugzilla.gnome.org/show_bug.cgi?id=795193
- Stop using a custom thread for listening to kqueue(2) events. Instead
call kevent(2) in non blocking mode in a monitor callback. Under the
hood poll(2) is used to figure out if new events are available.
- Do not use a socketpair with a custom protocol requiring 2 supplementary
context switches per event to commicate between multiple threads. Calling
kevent(2), in non blocking mode, to add/remove events is fine from any
context.
- Add kqueue(2) events without the EV_ONESHOT flag. This removes a race
where some notifications were lost because events had to be re-added for
every new notification.
- Get rid of the global hash table and its associated lock and races. Use
the 'cookie' argument of kevent(2) to pass the associated descriptor when
registering an event.
- Fix _kh_file_appeared_cb() by properly passing a monitor instead of a
source to g_file_monitor_emit_event().
- Properly refcount sources.
- Remove a lot of abstraction making it harder to fix the remaining issues.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
That event is deprecated, and the kqueue backend can’t provide enough
information to go alongside the event (i.e. the name of the new file).
Use G_FILE_MONITOR_EVENT_DELETED instead.
Quite disappointed in the kqueue documentation for this: I cannot find a
single piece of documentation or example about how NOTE_RENAME is
supposed to communicate the new name of the file.
If it turns out that this is possible, the code can be amended again in
future. At least now it doesn’t abort.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776147
Disable gio tests on Windows, fix .gitignore to not ignore
config.h.meson, and add more things to it.
Rename the library file naming and versioning to match what Autotools
outputs, e.g., libglib-2.0.so.0.5000.2 on Linux, libglib-2.0-0.dll and
glib-2.0-0.dll on Windows with MSVC.
Several more tiny fixes, more executables built and installed, install
pkg-config and m4 files, fix building of gobject tests.
Changes to gdbus-codegen to support out-of-tree builds without
environment variables set (which you can't in Meson). We now add the
build directory to the Python module search path.
Previously, _kh_cancel_sub assumed that it only needed to call
_km_remove if sub did not exist in subs_hash_table. This is erroneous
because the complementary operation, _km_add_missing, can be called
from process_kqueue_notifications, in which context sub can *only* have
come from subs_hash_table.
Since _km_remove is implemented using g_slist_remove, which is
documented to be a noop if the list does not contain the element to be
removed, it is safe to call _km_remove unconditionally here.
https://bugzilla.gnome.org/show_bug.cgi?id=778515
Cancellation of GPollFileMonitor is now handled correctly (in the sense
that no further signals will follow) but let's be extra paranoid and
disconnect our handler anyway, for good measure.
https://bugzilla.gnome.org/show_bug.cgi?id=739424
This is the bare minimal effort. This seems not to crash immediately,
but it definitely needs some better testing.
The backend is not in good shape. It could use some serious work.
In case an object is already monitored, we lock then return without
unlocking it which can then result in a self deadlock. So properly
unlock before returning.
https://bugzilla.gnome.org/show_bug.cgi?id=721074
Perform a substantial cleanup of the build system with respect to
building and installing testcases.
First, Makefile.decl has been renamed glib.mk and substantially
expanded. We intend to add more stuff here in the future, like canned
rules for mkenums, marshallers, resources, etc.
By default, tests are no longer compiled as part of 'make'. They will
be built when 'make check' is run. The old behaviour can be obtained
with --enable-always-build-tests.
--disable-modular-tests is gone (because tests are no longer built by
default). There is no longer any way to cause 'make check' to be a
no-op, but that's not very useful anyway.
A new glibtests.m4 file is introduced. Along with glib.mk, this
provides for consistent handling of --enable-installed-tests and
--enable-always-build-tests (mentioned above).
Port our various test-installing Makefiles to the new framework.
This patch substantially improves the situation in the toplevel tests/
directory. Things are now somewhat under control there. There were
some tests being built that weren't even being run and we run those now.
The long-running GObject performance tests in this directory have been
removed from 'make check' because they take too long.
As an experiment, 'make check' now runs the testcases on win32 builds,
by default. We can't run them under gtester (since it uses a pipe to
communicate with the subprocess) so just toss them in TESTS. Most of
them are passing on win32.
Things are not quite done here, but this patch is already a substantial
improvement. More to come.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
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.
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.
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
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
