This patch fixes several const qualifiers by adjusting where required.
Since glibc-2.43 and ISO C23, the functions bsearch, memchr, strchr,
strpbrk, strrchr, strstr, wcschr, wcspbrk, wcsrchr, wcsstr and wmemchr
that return pointers into their input arrays now have definitions as
macros that return a pointer to a const-qualified type when the input
argument is a pointer to a const-qualified type.
Signed-off-by: Rudi Heitbaum <rudi@heitbaum.com>
Prior to the addition of subsystem support in Meson, people who wanted
to cross-compile to iOS often set `system = 'ios'` in the cross file and
meson happily plumbed that to `host_machine.system()`.
However, we now use subsystems, so we should stop accepting
host_system == ios.
We use gmodule-dl.c on Cygwin, there's no point in keeping
Cygwin-specific code paths in gmodule-win32.c.
Note: the official Cygwin glib2 package patches meson.build
to use gmodule-win32.c. However:
1. It didn't use those Cygwin-specific code paths anyway.
2. We now include everything that Cygwin needs. The
official glib2 package need not patch meson.build
anymore.
While Cygwin has the standard dlopen/dlclose/dlsym APIs, one thing
it cannot handle is opening a module to find a symbol among its
dynamically linked dependencies. Here we implement a workaround
based on the Tool Help library.
Co-authored-by: Luca Bacci <luca.bacci@outlook.com>
There were no such warnings in this library, so we can
enable the warning flag to prevent any being added in future.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3527
There was only one `-Wsign-conversion` warning in the whole
subdirectory, so that was easy.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3405
This reverts commit bb2ab2647d.
It appears to break the use of `G_MODULE_BIND_LOCAL`, as evidenced by
the `test_local_binding()` test in `module-test.c` failing on FreeBSD
ever since that test was added. See #3415.
Looking back at the merge request (!3656), I should have pressed for
detail on why this change was needed.
Fixes: #3415
According to POSIX, the default behavior of `dlopen` is unspecified when
its flags include neither `RTLD_LOCAL` nor `RTLD_GLOBAL`. Consequently,
different platforms have different default behavior.
The default on Linux is `RTLD_LOCAL`, but the default on Darwin is
`RTLD_GLOBAL`. By passing `0` to `dlopen`, this results in the opposite
of the caller's intent when using `G_MODULE_BIND_LOCAL`.
Passing `RTLD_LOCAL` for `G_MODULE_BIND_LOCAL` allows the correct
behavior to be observed regardless of the platform's default.
Basically various trivial instances of the following MSVC compiler
warning:
```
../gio/gio-tool-set.c(50): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
When linking static libraries, multiple resources is an error unless
handled in a special way. glib and gobject do not have this problem,
as they already only include resources when building a shared lib.
Generating gir and typelib files has inter-dependencies that may depend
on other elements.
For example, glib requires gobject and gdump generated files require
gmodule, so we've a cyclic dependency because gmodule requires gobject,
that requires glib.
To prevent this, let's just generate the introspection files at once in
a different meson file so that we don't have to deal with this.
As per this we could even revert commit fa37ab6d0 since gio is now
compiled before the gir files.
Currently, the introspection data for GLib and its sub-libraries is
generated by gobject-introspection, to avoid the cyclic dependency
between the two projects.
Since gobject-introspection is generally available on installed systems,
we can check for its presence, and generate the introspection data
directly from GLib.
This does introduce a cyclic dependency, which is why it's possible to
build GLib without introspection, then build gobject-introspection, and
finally rebuild GLib.
By having introspection data available during the GLib build, we can do
things like generating documentation; validating newly added API; and
close the loop between adding new API and it becoming available to non-C
consumers of the C ABI (i.e. language bindings).
This reverts commit 004f48f4fc.
Per the discussion on #3356, this change was prompted by a
misunderstanding of ldflags/link_args, and it resulted in various other
packages using glib no longer getting symbols exported. This commit
restores the glib 2.76 behaviour.
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
Previously, `-Wl,--export-dynamic` was in `Libs` key of `gmodule-2.0.pc`,
even though `-Wl` is a compiler flag, rather than a linker one.
This caused issues with API reference builds in evolution-data-server,
which passes the output of `pkg-config --libs` through `--ldflags`
argument of `gtkdoc-scan`, which are forwarded unchanged to `ld`:
ld: unrecognized option '-Wl,--export-dynamic'
Let’s move the flag to `Cflags` so that the compiler can deal with it.
https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/463
In all these cases we don't really care about running the test file,
while building and basic execution it is relevant.
Also they don't support TAP at all.
Meson supports tap protocol results parsing, allowing us to track better
the tests that are running (and the ones that are actually skipped) without
manually parsing the test output.
However this also implies that using the verbose mode for a test doesn't
show its output by default (unless there are failures).
We cannot use `gvisibility_h` for different visibility header files; you
never know when you're going to refer to the variable again, and
projects might end up needing to retrieve the variable contents—like,
for instance, gobject-introspection using glib as a subproject.
This should fix the Coverity build, which is currently broken:
https://gitlab.gnome.org/GNOME/glib/-/jobs/2389979
```
../gmodule/gmodule-deprecated.c:8: error: "GLIB_DISABLE_DEPRECATION_WARNINGS" redefined [-Werror]
8 | #define GLIB_DISABLE_DEPRECATION_WARNINGS
|
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
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
