`HAVE_COCOA` should be used only in the places where we’re actually
depending on the Cocoa toolkit. It should not be used as a general way
of detecting building on a Darwin-based OS such as macOS.
Conversely, there are a few places in the code where we do want to
specifically detect the Cocoa toolkit (and others where we specifically
want to detect Carbon), so keep `HAVE_COCOA` and `HAVE_CARBON` around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2802
This reverts commit 476e33c3f3.
We’ve decided to remove `G_OS_DARWIN` in favour of recommending people
use `__APPLE__` instead. As per the discussion on #2802 and linked
issues,
* Adding a new define shifts the complexity from “which of these
platform-provided defines do I use” to “which platform-provided
defines does G_OS_DARWIN use”
* There should ideally be no cases where a user of GLib has to use
their own platform-specific code, since GLib should be providing
appropriate abstractions
* Providing a single `G_OS_DARWIN` to cover all Apple products (macOS
and iOS) hides the complexity of what the user is actually testing:
are they testing for the Mach kernel, the Carbon and/or Cocoa user
space toolkits, macOS vs iOS vs tvOS, etc
Helps: #2802
G_MODULE_SUFFIX is deprecated now because you will get the wrong
results using it most of the time:
1. The suffix on macOS is usually 'dylib', but it's 'so' when using
Autotools, so there's no way to get the suffix correct using
a pre-processor macro.
2. Prefixes also vary in a platform-specific way. You may or may not have
a 'lib' prefix for the name on Windows and on Cygwin the prefix is
'cyg'.
3. The library name itself can vary per platform. For instance, you may
want to load foo-1.dll on Windows and libfoo.1.dylib on macOS. This
is for libraries, not modules, but that is still a use-case that
people use the GModule API for.
g_module_build_path() does take care of (2) on Cygwin, but it
fundamentally cannot handle the possibility of multiple options for
the module name, since it does not do any I/O. Hence, it is also
deprecated.
Instead, g_module_open() has been improved so that it takes care of
all this by searching the filesystem for combinations of possible
suffixes and prefixes on each platform. Along the way, the
documentation for it was also improved to make it clearer what it
does.
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/520
Closes https://gitlab.gnome.org/GNOME/glib/-/issues/1413
A module must exist forever after it is loaded. If it's not referenced
anywhere, as with some gio tests, ASAN will report direct leaks. Silence
those.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This reverts commit ad0fd6c5d9.
The type system actually keeps a weak reference on the module/plugin.
g_type_module_unuse() documentation is explicit "Once a #GTypeModule is
initialized, it must exist forever."
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
GIOModule is a helper object, we keep it around when there is a cache,
but we should free it otherwise.
Found thanks to ASAN.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Add SPDX license (but not copyright) headers to all files which follow a
certain pattern in their existing non-machine-readable header comment.
This commit was entirely generated using the command:
```
git ls-files gio/*.[ch] | xargs perl -0777 -pi -e 's/\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/\n \*\n \* SPDX-License-Identifier: LGPL-2.1-or-later\n \*\n \* This library is free software; you can redistribute it and\/or\n \* modify it under the terms of the GNU Lesser General Public/igs'
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
It used to exist on Solaris, but GLib’s support for it was mostly
removed in 2015 in commit 21ab660cf8.
Remove the final few references.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This is intended to provide a uniform interface for controlling whether
the debug output from an application (or service) is emitted, typically
to journald, but actually to wherever the application chooses to output
it.
The main implementation of `GDebugController` is `GDebugControllerDBus`,
which is intended to be used on Linux. Other implementations may be
added in future for other platforms, or larger applications may want to
provide their own implementation which integrates with their ecosystem.
The `GDebugControllerDBus` implementation exposes a D-Bus interface at
`/org/gtk/Debugging` with a method to enable or disable debug
output at runtime.
This could be used by external harnesses, such as GNOME Builder or
systemd, to give a uniform way to get debug output from an application.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1190
Glib cannot be built statically on Windows because glib, gobject and gio
modules need to perform specific initialization when DLL are loaded and
cleanup when unloaded. Those initializations and cleanups are performed
using the DllMain function which is not called with static builds.
Issue is known for a while and solutions were already proposed but never
merged (see: https://gitlab.gnome.org/GNOME/glib/-/issues/692). Last
patch is from version 2.36.x and since then the
"constructor/destructor" mechanism has been implemented and used in
other part of the system.
This patch takes back the old idea and updates it to the last version of
glib to allow static compilation on Windows.
WARNING: because DllMain doesn't exist anymore in static compilation
mode, there is no easy way of knowing when a Windows thread finishes.
This patch implements a workaround for glib threads created by calling
g_thread_new(), so all glib threads created through glib API will behave
exactly the same way in static and dynamic compilation modes.
Unfortunately, Windows threads created by using CreateThread() or
_beginthread/ex() will not work with glib TLS functions. If users need
absolutely to use a thread NOT created with glib API under Windows and
in static compilation mode, they should not use glib functions within
their thread or they may encounter memory leaks when the thread finishes.
This should not be an issue as users should use exclusively the glib API
to manipulate threads in order to be cross-platform compatible and this
would be very unlikely and cumbersome that they may mix up Windows native
threads API with glib one.
Closes#692
Port all existing calls in GLib to the new API so that they can receive
more detailed error information (although none of them actually make use
of it at the moment).
This also serves to test the new API better through use.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #203
While all of the current callers of _g_io_module_get_default() want to
cache the returned GObject for the lifetime of the process, that doesn’t
necessarily have to be the case, so let callers make that decision on a
case-by-case basis.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Even if the modules in the given directory never get chosen to be used,
loading arbitrary code from a user-provided directory is not safe when
running as setuid, as the process’ environment comes from an untrusted
source.
Also ignore `GIO_EXTRA_MODULES`.
Spotted by Simon McVittie.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2168
It may be defined by the environment (we document that as being allowed)
— if so, individual files should not try to redefine it, as that causes
a preprocessor warning.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
In ostree based systems, such as flatpak and fedora silverblue, the
time of modification of every system file is epoch 0, including
giomodule.cache, which means that every module is loaded and unloaded
every time.
The solution is to use the change time of the file as well. In a typical
system, it is equal to the mtime, and in an ostree based system, since
the directory is mounted as read-only, the user cannot add a module and
we must assume that the cache file corresponds to the modules.
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>
This code uses, or tests, deprecated functions, types or macros; so
needs to be compiled with deprecation warnings disabled.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
It could've never been uninitialized in this code but the code flow is
not obvious to the compiler. Initialize it to NULL and for clarity also
add an assertion that it is not NULL anymore on usage.
In file included from ../glib/glib.h:62,
from ../gobject/gbinding.h:28,
from ../glib/glib-object.h:23,
from ../gio/gioenums.h:28,
from ../gio/giotypes.h:28,
from ../gio/giomodule.h:28,
from ../gio/giomodule.c:25:
../gio/giomodule.c: In function ‘_g_io_module_get_default’:
../glib/gmessages.h:343:25: warning: ‘extension’ may be used uninitialized in this function [-Wmaybe-uninitialized]
#define g_debug(...) g_log (G_LOG_DOMAIN, \
^~~~~
../gio/giomodule.c:912:17: note: ‘extension’ was declared here
GIOExtension *extension, *preferred;
^~~~~~~~~
Interpret the value "help" for environment variables that
are passed to _g_io_module_get_default(), and print the
names and priorities of available extensions.
This lets users explore what is available, and can be helpful
in figuring out why a certain extension was chosen as default.
It is similar in spirit to what we already do with environment
variables like G_DEBUG.
This is useful for debugging in many situations. It’ll be printed with
G_MESSAGES_DEBUG=GLib-GIO or G_MESSAGES_DEBUG=all.
Mostly I need it for debugging the default GNetworkMonitor, but it will
work for all GIO module implementations.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This adds a null notification backend implementation for win32, purely
to avoid crashes due to a missing backend when applications use
GNotification. This backend does nothing except print a warning when a
notification is supposed to be emitted.
In future, it can be expanded to use win32 API to present toaster
notifications appropriately.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=776583
Added a Windows backend to GNetworkMonitor, using NotifyRouteChange2()
(available on Vista and later). It marshals the route change callbacks
to the thread-specific default main context the GNetworkMonitor was
constructed in.
https://bugzilla.gnome.org/show_bug.cgi?id=685442
GIO modules should include their name into their exported symbols to
make them unique. This avoids symbol clash when building modules
statically.
extract_name() function is copied from GStreamer which recently
switched to the same symbol naming scheme.
https://bugzilla.gnome.org/show_bug.cgi?id=684282
Where we were already treating GHashTables as sets, modify them to use
the set-specific APIs g_hash_table_add() and g_hash_table_contains(), to
make that usage more obvious and less prone to being broken.
Heavily based on patches by Garrett Regier <garrettregier@gmail.com>.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=749371
It's unnecessary, and only adds visual noise; we have been fairly
inconsistent in the past, but the semi-colon-less version clearly
dominates in the code base.
https://bugzilla.gnome.org/show_bug.cgi?id=669355
This is an implementation of most of GAppInfo using the OS X
NSBundle APIs.
Missing at this point are things that don't have equivalents
in OS X, such as hidden desktop files, last-used, manual type
associations, and g_app_info_get_all().
https://bugzilla.gnome.org/show_bug.cgi?id=734946
