So they are consistent with the way we’re building man pages in other
projects, and because some people are allergic to XML.
This changes the build-time dependencies from `xsltproc` to `rst2man`,
and also takes the opportunity to change the `-Dman` Meson option from a
boolean to a feature (so you should use `-Dman-pages={enabled,disabled}`
now, rather than `-Dman={true,false}`).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
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.
Because the documentation is no longer built using gtk-doc.
Keep the old option around, but deprecated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3037
The `#include <langinfo.h>` in `gdatetime.c` is currently predicated on
`HAVE_LANGINFO_TIME`, but it’s needed for all the `HAVE_LANGINFO_*`
features.
It seems the code implicitly assumes that `HAVE_LANGINFO_TIME` will be
true if any other `HAVE_LANGINFO_*` macros are true. While I haven’t
seen this assumption be broken in practice, it seems prudent to
explicitly encode that in the configure tests. It’s easy enough to do.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The `%E` modifier causes dates to be formatted using an alternative era
representation for years. This doesn’t do anything for most dates, but
in locales such as Thai and Japanese it causes years to be printed using
era names.
In Thai, this means the Thai solar calendar
(https://en.wikipedia.org/wiki/Thai_solar_calendar). In Japanese, this
means Japanese era names
(https://en.wikipedia.org/wiki/Japanese_era_name).
The `%E` modifier syntax follows what’s supported in glibc — see
nl_langinfo(3).
Supporting this is quite involved, as it means loading the `ERA`
description from libc and parsing it.
Unit tests are included.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
Fixes: #3119
The test needs to call `ftruncate64()` (not `ftruncate()`) to guarantee
it’s using the 64-bit version on Linux, but this doesn’t exist on other
platforms.
Test to see if it exists and, if not, skip the test.
Fixes commit cf5e371c67, and fixes CI
failures like https://gitlab.gnome.org/GNOME/glib/-/pipelines/602930.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
The PTRACE_O_EXITKILL symbol in sys/ptrace.h is an enum member, not
a macro. The #ifdef check added to the GSubprocess test-case in
272ec5dbca will not detect it.
Use cc.has_header_symbol() to properly detect it. According to the
documentation: "Symbols here include function, variable, #define,
type definition, etc.".
Fixes: 272ec5dbca
Closes: https://gitlab.gnome.org/GNOME/glib/-/issues/3156
And update all the CI builds to use the latest micro release from that
series, 1.2.3.
This version bump means we can:
- Drop some backwards-compatibility Meson checks
- Fix a periodic CI failure caused by a now-fixed Meson bug
(https://github.com/mesonbuild/meson/pull/10633)
It’s in line with our [Meson version policy](./docs/meson-version.md),
as Meson 1.2.1 is available in
[Debian Trixie](https://packages.debian.org/source/trixie/meson) and the
[freedesktop SDK](c95902f2ed/elements/components/meson.bst).
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
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).
The introspection API has lived out of tree far too long. It has the
same ABI guarantees as the rest of GLib, so it has no reason to be split
from the main library.
The gobject-introspection project can depend on libgirepository, and the
language bindings can drop the gobject-introspection-1.0 dependency.
If glib and PCRE2 are both built for Windows as subprojects of a parent
project, cc.links() will fail because PCRE2 hasn't been built yet when
glib is being configured:
subprojects/glib-2.78.0/meson.build:2109:20: ERROR: Dependencies must be external dependencies
609d58beea changed the detection logic to avoid cc.links() in this
case, but dd5683ce64 broke it again. PCRE2 detection could use a
broader cleanup, but for now, make the minimum change to fix this case.
use_pcre2_static_flag ends up set to false, matching the behavior of
609d58beea.
Fixes: dd5683ce64 ("meson: Allow fallback & static build of pcre subproject")
GCC >= 4.7 and clang >= 12 don't need it. It should be left to the user
to decide what ABI convention should be used, and it creates some issues
with some tools to have this flag in cflags.
We leave the flag for now, but print a warning at compile time so people
get a chance to change their build system before we drop it from glib.pc
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This reverts commit 252bbcd207.
After further discussion in !3511, we’ve decided that there are risks
associated with this change, and it’s not the best way of addressing the
original problem.
The original motivation for the change turned out to be that
`-mms-bitfields` was not handled by `windres`, which was receiving it
from `pkg-config --cflags glib-2.0` in some projects. However, if
`windres` is claiming to accept CFLAGS then it should accept (and
ignore) `-mms-bitfields`, since the `-m` family of options are defined
in `man gcc`, just like `-I`, `-D`, etc.
There is some question that there might still be third party projects
which are built with an old enough compiler that `-mms-bitfields` is not
the compiler default. For that reason, we should either still continue
to specify `-mms-bitfields` in the `.pc` file, or add a test to assert
that third party projects are always compiled with `-mms-bitfields` set.
But adding a new test for all third-party compilations is risky (if we
get it wrong, things will break; and it’s a test which may behave
differently on different platforms), so it seems safer to just keep
`-mms-bitfields` in `.pc` for now.
Once all compilers which we require specify `-mms-bitfields` by default,
we can finally drop this flag (without adding a test for third-party
compilations).
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3511
Otherwise, crashing tests like assert-msg-test will still report to
pipe-based crash reporting frameworks like systemd-coredump, even though
the RLIMIT_CORE limit is zero.
Signed-off-by: Simon McVittie <smcv@collabora.com>
gobject-introspection is currently assuming glib subproject
is in unversioned, but gstreamer uses a versioned directory, eg:
subprojects/glib-2.74.1 instead of subprojects/glib
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.
Using `allow_fallback: false` on the first check for libpcre
was unnecessary, as `required: false` already disables using
fallbacks. `allow_fallback: false` meant that
`--force-fallback-for` couldn’t work. This commit fixes that.
Also allow the fallback libpcre to be built statically so it
can be linked into GLib.
Helps: #3025
This was originally removed in !2734 but still appears to be required for
some MinGW setups, such as the `x86_64-w64-mingw32.static` target in
[mxe](https://github.com/mxe/mxe).
Currently, this configuration fails the libintl internal assert on line
2128, as on this platform `ngettext()` is only found inside libiconv.
This commit will look up iconv potentially twice, once as `libiconv` and
potentially once as `libintl_iconv`. This is what the code did before
!2734 landed, so it’s known to work reliably on a number of platforms.
This allows the `g_free()` wrapper introduced in the previous commit to
only be defined if `free_sized()` is actually available to improve
performance.
This avoids passing an allocation size to every `g_free()` call if it’s
not going to be used, saving a register store instruction each time.
Suggested by Marco Trevisan in
https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3252#note_1660032
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
When `copy_file_range()` support was added, I used the definition of
`copy_file_range()` from Linux, which uses `loff_t` to abstract the
different `off*_t` types.
`loff_t` doesn’t exist on FreeBSD, so this doesn’t compile, and was
caught in subsequent asynchronous CI.
Define `loff_t` with a fallback value if it’s not defined, which should
fix this and other uses of `loff_t` in `gfile.c` (for example, if
FreeBSD ever starts declaring `splice()`).
Fixes this CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/2812302
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
While it can’t be used in all situations, it is a little bit faster than
`splice()` in some situations, basically if the file system supports
copy on write. In other situations it’s no slower than `splice()`.
See `man copy_file_range` for the situations where it doesn’t work. In
all of these situations, it will return an error, and the GLib code will
fall through and try the existing `splice()` copy code instead.
From my testing of `time gio copy A B` with a 9GB file, the `splice()`
code path takes 22s, and the `copy_file_range()` code path takes 20s.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2863
When cross-building with a non-Linux target, linux/netlink.h will not
actually be buildable, even if distributions typically put it in
/usr/include and thus exposed to the cross-compiler.
