See README.md

[
    {
        "Name": "openEuler:glib2",
        "License": "LGPL V2.1",
        "License File": "COPYING",
        "Version Number": "2.72.2-12.oe2203sp3",
        "Upstream URL": "https://www.gtk.org/",
        "Description": "GLib is the low-level core library that forms the basis for projects such as GTK and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system."
  }
]

# GLib

GLib is the low-level core library that forms the basis for projects such
as GTK and GNOME. It provides data structure handling for C, portability
wrappers, and interfaces for such runtime functionality as an event loop,
threads, dynamic loading, and an object system.

The official download locations are:
  <https://download.gnome.org/sources/glib>

The official web site is:
  <https://www.gtk.org/>

## Installation

See the file '[INSTALL.in](INSTALL.in)'

## Supported versions

Only the most recent unstable and stable release series are supported. All
older versions are not supported upstream and may contain bugs, some of
which may be exploitable security vulnerabilities.

See [SECURITY.md](SECURITY.md) for more details.

## Documentation

API documentation is available online for GLib for the:
 * [GLib](https://docs.gtk.org/glib/)
 * [GObject](https://docs.gtk.org/gobject/)
 * [GModule](https://docs.gtk.org/gmodule/)
 * [GIO](https://docs.gtk.org/gio/)

## Discussion

If you have a question about how to use GLib, seek help on [GNOME’s Discourse
instance](https://discourse.gnome.org/tags/glib). Alternatively, ask a question
on [StackOverflow and tag it `glib`](https://stackoverflow.com/questions/tagged/glib).

## Reporting bugs

Bugs should be [reported to the GNOME issue tracking system](https://gitlab.gnome.org/GNOME/glib/issues/new).
You will need to create an account for yourself. You may also submit bugs by
e-mail (without an account) by e-mailing <incoming+gnome-glib-658-issue-@gitlab.gnome.org>,
but this will give you a degraded experience.

Bugs are for reporting problems in GLib itself, not for asking questions about
how to use it. To ask questions, use one of our [discussion forums](#discussion).

In bug reports please include:

* Information about your system. For instance:
  * What operating system and version
  * For Linux, what version of the C library
  * And anything else you think is relevant.
* How to reproduce the bug.
  * If you can reproduce it with one of the test programs that are built
  in the `tests/` subdirectory, that will be most convenient.  Otherwise,
  please include a short test program that exhibits the behavior.
  As a last resort, you can also provide a pointer to a larger piece
  of software that can be downloaded.
* If the bug was a crash, the exact text that was printed out
  when the crash occurred.
* Further information such as stack traces may be useful, but
  is not necessary.

## Contributing to GLib

Please follow the [contribution guide](./CONTRIBUTING.md) to know how to
start contributing to GLib.

Patches should be [submitted as merge requests](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/new)
to gitlab.gnome.org. If the patch fixes an existing issue, please refer to the
issue in your commit message with the following notation (for issue 123):
```
Closes: #123
```

Otherwise, create a new merge request that introduces the change. Filing a
separate issue is not required.

## Default branch renamed to `main`

The default development branch of GLib has been renamed to `main`. To update
your local checkout, use:
```sh
git checkout master
git branch -m master main
git fetch
git branch --unset-upstream
git branch -u origin/main
git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
```

This file documents various major decisions which affect GLib development,
giving a brief rationale of each decision, plus a link to further discussion.


 * Compiler attributes: https://bugzilla.gnome.org/show_bug.cgi?id=113075#c46

   GLib uses GIR annotations instead of compiler attributes. They are tidier,
   already supported by GLib and GNOME tools, and accomplish the same task as
   compiler attributes. GLib does not provide macros for attributes like
   nonnull because it would not use them.

 * Main loop API:

   The ID-based mainloop APIs (g_idle_add, g_timeout_add, etc) are considered
   legacy, and new features (such as g_source_set_static_name) will only be
   added to the explicit GSource APIs.

See README.win32.md

Chun-wei Fan `<fanc999@yahoo.com.tw>`
Philip Withnall `<withnall@endlessm.com>`
Nirbheek Chauhan `<nirbheek@centricular.com>`

This document was last updated in 2019. You're reading this in the future, and
lots of information might be misleading or outdated in your age. You have been
warned.

# General

For prebuilt binaries (DLLs and EXEs) and developer packages (headers,
import libraries) of GLib, Pango, GTK+ etc for Windows, go to
https://www.gtk.org/download/windows.php . They are for "native"
Windows meaning they use the Win32 API and Microsoft C runtime library
only. No POSIX (Unix) emulation layer like Cygwin is involved.

To build GLib on Win32, you can use either GCC ("MinGW") or the Microsoft
Visual Studio toolchain. For the latter, Visual Studio 2015 and later are
recommended. For older Visual Studio versions, see below.

You can also cross-compile GLib for Windows from Linux using the
cross-compiling mingw packages for your distro.

Note that to just *use* GLib on Windows, there is no need to build it
yourself.

On Windows setting up a correct build environment is very similar to typing
`meson; ninja` like on Linux.

The following preprocessor macros are to be used for conditional
compilation related to Win32 in GLib-using code:

- `G_OS_WIN32` is defined when compiling for native Win32, without
  any POSIX emulation, other than to the extent provided by the
  bundled Microsoft C library.

- `G_WITH_CYGWIN` is defined if compiling for the Cygwin
  environment. Note that `G_OS_WIN32` is *not* defined in that case, as
  Cygwin is supposed to behave like Unix. `G_OS_UNIX` *is* defined by a GLib
  for Cygwin.

- `G_PLATFORM_WIN32` is defined when either `G_OS_WIN32` or `G_WITH_CYGWIN`
  is defined.

These macros are defined in `glibconfig.h`, and are thus available in
all source files that include `<glib.h>`.

Additionally, there are the compiler-specific macros:
- `__GNUC__` is defined when using GCC or Clang
- `__clang__` is defined when using Clang or Clang-CL
- `_MSC_VER` is defined when using MSVC or Clang-CL

`G_OS_WIN32` implies using the Microsoft C runtime, which used to be
`msvcrt.dll` and is now the [Universal CRT](https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=vs-2015)
when building with Visual Studio. When using the MinGW-GCC toolchain, the CRT
in use depends on the settings used while the toolchain was built. We highly
recommend [using the Universal CRT when building with
MinGW](https://mingwpy.github.io/ucrt.html) too.

GLib is not actively tested with the static versions of the UCRT, but if you
need to use those, patches are welcome.

# Building software that use GLib or GTK+

Building software that just *uses* GLib or GTK+ also require to have
the right compiler set up the right way. If you intend to use MinGW-GCC,
follow the relevant instructions below in that case, too.

You should link to GLib using the `-mms-bitfields` GCC flag. This flag means
that the struct layout rules are identical to those used by MSVC. This is
essential if the same DLLs are to be usable both from gcc- and MSVC-compiled
code.

## Cross-CRT issues

You should take care that the DLLs that your code links to are using the same
C runtime library. Not doing so can and likely will lead to panics and crashes
**unless** you're very careful while passing objects allocated by a library
linked with one CRT to a library linked to another CRT, or (more commonly) not
doing that at all.

If you *do* pass CRT objects across CRT boundaries, do not file any issues
about whatever happens next.

To give an example, opening a `FILE` handle created by one CRT cannot be
understood by any other CRT, and will lead to an access violation. You also
cannot allocate memory in one CRT and free it using another.

There are [many other cases where you must not allow objects to cross CRT boundaries](https://docs.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=vs-2019),
but in theory if you're **very very** careful, you can make things work. Again,
please do not come to us for help if you choose to do this.

# Building GLib

You can build GLib with MinGW-GCC, MSVC, or (experimentally) with Clang-CL.

For all compilers, you will need the following:

- Install Python 3.6.x or newer, either 32-bit or 64-bit. We recommend enabling
  the option to add it to your `PATH`.
- [Install Meson](https://mesonbuild.com/Getting-meson.html)
- Install the [Ninja build tool](https://github.com/ninja-build/ninja/releases), which can also be
  installed with `pip3`. You can skip this step if you want to generate Visual
  Studio project files.
- [git for Windows](https://gitforwindows.org/) is required, since Meson makes
  use of git to download dependencies using subprojects.

## Building with MinGW-GCC

Open your MSYS or [MSYS2](https://www.msys2.org/) shell where you have the
MinGW-GCC toolchain installed, and build GLib [like any other Meson
project](https://mesonbuild.com/Quick-guide.html#compiling-a-meson-project).

## Building with Visual Studio 2015 or newer

Meson is now the only supported method of building GLib using Visual Studio.

To do a build using Meson, do the following:

- Open a Visual Studio (or SDK) command prompt that matches the Visual Studio
  version and build platform (Win32/x86, x64, etc.) that will be used in all
  the following steps.

- Create an empty directory/folder for the build inside your GLib sources
  directory, say, `_builddir`, and `cd` into it.

- Set up the build using Meson:

```cmd
> meson .. --buildtype=<release|debug|debugoptimized> --prefix=<path> [--backend=vs]
```

 Please see [the Meson docs](https://mesonbuild.com/Builtin-options.html#core-options)
 for an explanation for `--buildtype`.

 The path passed for `--prefix` need not to be on the same drive as where the
 build is carried out, but it is recommended to use forward slashes for this
 path.  The `--backend=vs` option can be used if the Visual Studio project
 generator is preferred over using Ninja.

- Build, test and install the build:
  Run `ninja` to build, `meson test` to test and `meson install` to install the
  build. If you used `--backend=vs`, instead of running `ninja`, you need to
  use `msbuild` or you can open the generated solution in Visual Studio.

## Building with old versions of Visual Studio

The steps are the same as above, with the following notes about issues that you might face.

### C4819 build errors

If you are building GLib-based libraries or applications, or GLib itself
and you see a `C4819` error (or warning, before `C4819` is treated as an error
in `msvc_recommended_pragmas.h`), please be advised that this error/warning should
not be disregarded, as this likely means portions of the build are not being
done correctly, as this is an issue of Visual Studio running on CJK (East Asian)
locales.  This is an issue that also affects builds of other projects, such as
QT, Firefox, LibreOffice/OpenOffice, Pango and GTK, along with many other projects.

To overcome this problem, please set your system's locale setting for non-Unicode to
English (United States), reboot, and restart the build, and the code should build
normally.

### Support for pre-2012 Visual Studio

This release of GLib requires at least the Windows 8 SDK in order to be built
successfully using Visual Studio, which means that it is no longer supported to
build GLib with Visual Studio 2008 nor 2010.  People that still need to use
Visual Studio 2008 or 2010 should continue to use glib-2.66.x.