luc14n0/glib
1
0
Fork 0
mirror of https://gitlab.gnome.org/GNOME/glib.git synced 2024-10-28 18:16:16 +01:00
Code Issues Packages Projects Releases Wiki Activity
main
glib/docs/supported-platforms.md
Philip Withnall 3348e942b2
docs: Document 32-bit support policy 
Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Fixes: #3477
2024-10-18 13:59:23 +01:00

6.0 KiB
Raw Permalink Blame History

Supported platforms

GLib’s approach to portability is that we only support systems that we can test. That means that either a large number of GLib developers are regularly using GLib on a particular system, or we have regular builds of GLib on that system.

Minimum versions

This list is authoritative, and documents what this version of GLib targets to support. The list will be periodically updated for the development branch, with versions typically being updated as they lapse from receiving support from their vendor.

Tested platforms

GLib is regularly built on at least the following systems:

If other platforms are to be supported, we need to set up regular CI testing for them. Please contact us if you want to help.

Policy and rationale

Due to their position in the market, we consider supporting GNU/Linux, Windows and macOS to be the highest priorities and we will go out of our way to accommodate these systems, even in places that they are contravening standards.

In general, we are open to the idea of supporting any Free Software UNIX-like system with good POSIX compliance. We are always interested in receiving patches that improve our POSIX compliance — if there is a good POSIX equivalent for a platform-specific API that we’re using, then all other things equal, we prefer the POSIX one.

We may use a non-POSIX API available on one or more of our supported systems in the case that it provides some advantage over the POSIX equivalent (such as the case with pipe2() solving the O_CLOEXEC race). In these cases, we will try to provide a fallback to the pure POSIX approach. If we’ve used a system-specific API without providing a fallback to a largely-equivalent POSIX API then it is likely a mistake, and we’re happy to receive a patch to fix it.

We are not interested in supporting other systems if it involves adding code paths that we cannot test. Specifically, this means that we will reject patches that introduce platform-specific #ifdef sections in the code unless we are actively doing builds of GLib on this platform (ie: see the lists above). We’ve historically accepted such patches from users of these systems on an ad hoc basis, but it created an unsustainable situation. Patches that fix platform-specific build issues in such a way that the code is improved in the general case are of course welcome.

Although we aim to support all systems with good POSIX compliance, we are not interested in adhering to “pure POSIX and nothing else”. If we need to add a feature and we can provide good support on all of the platforms that we support (above), we will not hold back for other systems. We will always try to provide a fallback to a POSIX-specified approach, if possible, or to simply replace a given functionality with a no-op, but even this may not be possible in cases of critical functionality.

32-bit support

GLib will support 32-bit systems as long as they are supported by any of the tested platforms above. This means we are guaranteed to be able to test our 32-bit build in CI.

In particular, Debian continues to support 32-bit installations on x86 as containers or chroots, though it doesn’t support running on 32-bit physical x86 hardware. It also supports a 32-bit armhf kernel and userspace.

As of 2024, other known significant consumers of 32-bit GLib are:

Notes on specific features

Note that we currently depend on a number of features specified in POSIX, but listed as optional:

Also see toolchain requirements.