libgirepository is not needed by most of the modules, but it is needed
by the `g-ir-scanner` generated dumper program. If we don’t explicitly
include the local version of it here, Meson will implicitly link against
it anyway, and that might pull in a different version, or try to link
against a half-built local version as the build ordering dependency tree
won’t reflect this relationship.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3401
When the file name is too long (for example, more than 238 bytes on
ext4), this will cause the creation of the .trashinfo file to fail.
Let's shorten the .trashinfo filename in this case, after all the
trash specification only requires unique filenames (see
`Contents of a trash directory` section in
https://specifications.freedesktop.org/trash-spec/trashspec-latest.html).
This should test the limits of loading 4GB files on i386 platforms, such
as the Hurd CI runner. On such platforms, `sizeof(size_t) == 4`.
This should fix the compiler warning from
https://gitlab.gnome.org/GNOME/glib/-/jobs/3989442:
```
../gio/tests/file.c:2931:51: error: left shift count >= width of type [-Werror=shift-count-overflow]
2931 | static const gsize testfile_4gb_size = ((gsize) 1 << 32) + (1 << 16); /* 4GB + a bit */
| ^~
cc1: all warnings being treated as errors
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
They take too long to include in a normal test run. They’ll still be run
in CI once a week as part of our scheduled slow test job.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The tests - one for sync, one for async - create a sparse file for
this purpose, so this should be cheap on the fileystem.
Of course, the test still allocates >4GB of memory for the data that it
returns from g_file_load_contents(), I hope the CI test runners can deal
with that.
GByteArray is limited to 4GB in size and the current code silently
overflows when that happens.
Replace both load_contents() and load_contents_async() implementations
with a version that uses realloc() and gsize to maintain the array.
The default values for construct properties always have to be set, even
if those properties are deprecated. The code to do that is in GLib, and
not under the control of the user (unless they completely override the
`constructor` vfunc, which is not recommended). So don’t emit a warning
for that if `G_ENABLE_DIAGNOSTICS` is enabled.
In particular, this fixes deprecation warnings being emitted for
properties of a parent class when chaining up with a custom constructor,
even when none of the child class code mentions the deprecated property.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3254
Disable tests that require update-desktop-database when it is missing.
It requires glib to build so it will be missing when bootstrapping glib.
Refactor the ifdef for Windows and MacOS while at it and reduce number
of ifdefs.
Ref: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3658
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
shared-mime-info required glib to build and will not be there during
bootstrap. Skip the test if it is missing.
ref: https://gitlab.gnome.org/GNOME/glib/-/issues/3317
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
Without the -Wno-typedef-redefinition option, clang complains if a typedef
gets redefined in gnu99 mode (since this is officially a C11 feature). This
also happened with old versions of GCC.
So, don't break the build on such warn, since we want to support
toolchains that supports C11 anyways.
We have required C99 for a while; in the meantime, most C toolchains
have moved on to C11 or later as the default C standard.
We still allow for C99 toolchains, but in the future we are going to
require a C11 toolchain to build and use GLib.
It seems to have been accidentally enabled by the switch to making
dtrace a Meson feature. This has only just been caught because the
FreeBSD CI runner has been offline for several weeks (see
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1503).
With dtrace enabled, the FreeBSD CI build fails with:
```
[8/1601] Generating 'gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o'
FAILED: gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
/usr/sbin/dtrace -G -s ../gobject/gobject_probes.d -o gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
dtrace: failed to link script ../gobject/gobject_probes.d: No probe sites found for declared provider
[9/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.h' (wrapped by meson because command contains newlines)
[10/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.o'
FAILED: glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
/usr/sbin/dtrace -G -s ../glib/glib_probes.d -o glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
dtrace: failed to link script ../glib/glib_probes.d: No probe sites found for declared provider
```
(see https://gitlab.gnome.org/GNOME/glib/-/jobs/3961782)
I have no idea how to fix that, and it’s presumably not been working for
a long time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Previously it was mapped (as a default) to `G_IO_ERROR_FAILED`.
It’s the error that macOS returns when trying to connect to a socket which
is bound but not listened to. Linux returns `ECONNREFUSED` in this case.
It’s helpful if they both map to the same `GIOError` value.
This should fix the `/socket-client/connection-fail` test on macOS,
which is currently
[failing](https://gitlab.gnome.org/GNOME/glib/-/jobs/3970547) with:
```
# GLib-GIO-DEBUG: GSocketClient: Starting TCP connection attempt
# GLib-GIO-DEBUG: GSocketClient: Connection attempt failed: Can't assign requested address
# GLib-GIO-DEBUG: GSocketClient: Starting new address enumeration
# GLib-GIO-DEBUG: GSocketClient: Address enumeration completed (out of addresses)
# GLib-GIO-DEBUG: GSocketClient: Address enumeration failed: (null)
# GLib-GIO-DEBUG: GSocketClient: Connection failed: Could not connect to localhost: Can't assign requested address
not ok /socket-client/connection-fail - GLib-GIO:ERROR:../gio/tests/gsocketclient-slow.c:231:test_connection_failed: assertion failed (local_error == (g-io-error-quark, 39)): Could not connect to localhost: Can't assign requested address (g-io-error-quark, 0)
Bail out!
```
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
See: #3184Fixes: #3394
It seems to have been accidentally enabled by the switch to making
dtrace a Meson feature. This has only just been caught because the
FreeBSD CI runner has been offline for several weeks (see
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1503).
With dtrace enabled, the FreeBSD CI build fails with:
```
[8/1601] Generating 'gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o'
FAILED: gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
/usr/sbin/dtrace -G -s ../gobject/gobject_probes.d -o gobject/libgobject-2.0.so.0.8100.0.p/gobject_probes.o
dtrace: failed to link script ../gobject/gobject_probes.d: No probe sites found for declared provider
[9/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.h' (wrapped by meson because command contains newlines)
[10/1601] Generating 'glib/libglib-2.0.so.0.8100.0.p/glib_probes.o'
FAILED: glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
/usr/sbin/dtrace -G -s ../glib/glib_probes.d -o glib/libglib-2.0.so.0.8100.0.p/glib_probes.o
dtrace: failed to link script ../glib/glib_probes.d: No probe sites found for declared provider
```
(see https://gitlab.gnome.org/GNOME/glib/-/jobs/3961782)
I have no idea how to fix that, and it’s presumably not been working for
a long time.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Once the task is completed (and `g_task_return_*()` has been called),
the task is no longer needed. It would make more sense to unref it in
`complete_connection_with_error()`, where `g_task_return_*()` is called,
but that complicates other call sites significantly, so I didn’t do it.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3184
Some of these are properties of a Standard C or POSIX platform that
are true by definition and checked for completeness (for example intptr_t
is defined to be signed, and uintptr_t unsigned), while others are
checking that GLib's type detection has been done correctly.
Signed-off-by: Simon McVittie <smcv@debian.org>
As a special case, keep the historical behaviour of treating gchar
as being signed, both on platforms where it is genuinely signed (for
example x86 Linux) and where it is unsigned (for example ARM, s390x
and PowerPC Linux). Changing gchar to use INTEGER_ALIAS would have a
regression risk, so if we want to do that, it should be as a separate
change.
No functional change intended.
Signed-off-by: Simon McVittie <smcv@debian.org>
It’s currently completely untested. Let’s add a few basic tests so that
adding more tests in future is easier.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
