openharmony/third_party_glib
1
0
Fork 0
mirror of https://gitee.com/openharmony/third_party_glib synced 2024-11-23 09:49:46 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

OAT整改 Signed-off-by: s30029175 <shiqiwei4@huawei.com>

Browse Source 
Signed-off-by: sqwlly <shiqiwei4@huawei.com>
Change-Id: I9ac6fd98ef3de8289346d2dcce7ce20ad5398bf8
This commit is contained in:
sqwlly 2023-06-14 11:52:05 +08:00
parent 790524a04d
commit 025847c86f
8 changed files with 589 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

274
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,274 @@
# Contribution guidelines
Thank you for considering contributing to the GLib project!
These guidelines are meant for new contributors, regardless of their level
of proficiency; following them allows the core developers of the GLib project to
more effectively evaluate your contribution, and provide prompt feedback to
you. Additionally, by following these guidelines you clearly communicate
that you respect the time and effort that the people developing GLib put into
managing the project.
GLib is a complex free software utility library, and it would not exist without
contributions from the free and open source software community. There are
many things that we value:
- bug reporting and fixing
- documentation and examples
- tests
- testing and support for other platforms
- new features
Please, do not use the issue tracker for support questions. If you have
questions on how to use GLib effectively, you can use:
- the `#gtk` IRC channel on irc.gnome.org
- the [`glib` tag on GNOME's Discourse](https://discourse.gnome.org/tags/glib)
You can also look at the [`glib` tag on Stack
Overflow](https://stackoverflow.com/questions/tagged/glib).
The issue tracker is meant to be used for actionable issues only.
## How to report bugs
### Security issues
You should not open a new issue for security related questions.
When in doubt, send an email to the [security](mailto:security@gnome.org)
mailing list.
### Bug reports
If you’re reporting a bug make sure to list:
0. which version of GLib are you using?
0. which operating system are you using?
0. the necessary steps to reproduce the issue
0. the expected outcome
0. a description of the behavior
0. a small, self-contained example exhibiting the behavior
If the issue includes a crash, you should also include:
0. the eventual warnings printed on the terminal
0. a backtrace, obtained with tools such as GDB or LLDB
If the issue includes a memory leak, you should also include:
0. a log of definite leaks from a tool such as [valgrind’s
memcheck](http://valgrind.org/docs/manual/mc-manual.html)
For small issues, such as:
- spelling/grammar fixes in the documentation,
- typo correction,
- comment clean ups,
- changes to metadata files (CI, `.gitignore`),
- build system changes, or
- source tree clean ups and reorganizations;
or for self-contained bug fixes where you have implemented and tested a solution
already, you should directly open a merge request instead of filing a new issue.
### Features and enhancements
Feature discussion can be open ended and require high bandwidth channels; if
you are proposing a new feature on the issue tracker, make sure to make
an actionable proposal, and list:
0. what you’re trying to achieve and the problem it solves
0. three (or more) existing pieces of software which would benefit from the
new feature
0. how the feature is implementable on platforms other than Linux
New APIs, in particular, should follow the ‘rule of three’, where there should
be three (or more) pieces of software which are ready to use the new APIs. This
allows us to check that the new APIs are usable in real-life code, and fit well
with related APIs. This reduces the chances of awkward or unusable APIs becoming
stable in GLib and having to be supported forever.
A common way to introduce new APIs or data types to GLib is to prototype them in
another code base for a while, to gain real-life experience with them before
they are imported into GLib and marked as stable.
Each feature should also come fully documented, and with tests which approach
full branch coverage of the new code. GLib’s CI system generates code coverage
reports which are viewable for each merge request.
If proposing a large feature or change, it’s better to discuss it (on the
`#gtk` IRC channel or on [Discourse](https://discourse.gnome.org) before
putting time into writing an actionable issue — and certainly before putting
time into writing a merge request.
## Your first contribution
### Prerequisites
If you want to contribute to the GLib project, you will need to have the
development tools appropriate for your operating system, including:
- Python 3.x
- Meson
- Ninja
- Gettext (19.7 or newer)
- a [C99 compatible compiler](https://wiki.gnome.org/Projects/GLib/CompilerRequirements)
Up-to-date instructions about developing GNOME applications and libraries
can be found on [the GNOME Developer Center](https://developer.gnome.org).
The [GLib project uses GitLab](https://gitlab.gnome.org/GNOME/glib/) for code
hosting and for tracking issues. More information about using GitLab can be
found [on the GNOME wiki](https://wiki.gnome.org/GitLab).
### Getting started
You should start by forking the GLib repository from the GitLab web UI, and
cloning from your fork:
```sh
$ git clone https://gitlab.gnome.org/yourusername/glib.git
$ cd glib
```
**Note**: if you plan to push changes to back to the main repository and
have a GNOME account, you can skip the fork, and use the following instead:
```sh
$ git clone git@gitlab.gnome.org:GNOME/glib.git
$ cd glib
```
To compile the Git version of GLib on your system, you will need to
configure your build using Meson:
```sh
$ meson _builddir .
$ cd _builddir
$ ninja
```
Typically, you should work on your own branch:
```sh
$ git checkout -b your-branch
```
Once you’ve finished working on the bug fix or feature, push the branch
to the Git repository and open a new merge request, to let the GLib
core developers review your contribution.
### Code reviews
Each contribution is reviewed by the core developers of the GLib project.
The [CODEOWNERS](./docs/CODEOWNERS) document contains the list of core
contributors to GLib and the areas for which they are responsible; you
should ensure to receive their review and signoff on your changes.
It is our intention that every commit to GLib is reviewed by at least one other
person, including commits from core developers. We all make mistakes and can
always learn from each other, and code review allows that. It also reduces
[bus factor](https://en.wikipedia.org/wiki/Bus_factor) by spreading knowledge
of each commit between at least two people.
With each code review, we intend to:
0. Identify if this is a desirable change or new feature. Ideally for larger
features this will have been discussed (in an issue, on IRC, or on Discourse)
already, so that effort isn’t wasted on putting together merge requests
which will be rejected.
0. Check the design of any new API.
0. Provide realistic estimates of how long a review might take, if it can’t
happen immediately.
0. Ensure that all significant contributions of new code, or bug fixes, are
adequately tested, either through requiring tests to be submitted at the
same time, or as a follow-up.
0. Ensure that all new APIs are documented and have [introspection
annotations](https://wiki.gnome.org/Projects/GObjectIntrospection/Annotations).
0. Check that the contribution is split into logically separate commits, each
with a good commit message.
0. Encourage further high quality contributions.
0. Ensure code style and quality is upheld.
If a code review is stalled (due to not receiving comments for two or more
weeks; or due to a technical disagreement), please ping another GLib core
developer on the merge request, or on IRC, to ask for a second opinion.
### Commit messages
The expected format for git commit messages is as follows:
```plain
Short explanation of the commit
Longer explanation explaining exactly what’s changed, whether any
external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too
brief.
Closes #1234
```
- Always add a brief description of the commit to the _first_ line of
the commit and terminate by two newlines (it will work without the
second newline, but that is not nice for the interfaces).
- First line (the brief description) must only be one sentence and
should start with a capital letter unless it starts with a lowercase
symbol or identifier. Don’t use a trailing period either. Don’t exceed
72 characters.
- The main description (the body) is normal prose and should use normal
punctuation and capital letters where appropriate. Consider the commit
message as an email sent to the developers (or yourself, six months
down the line) detailing **why** you changed something. There’s no need
to specify the **how**: the changes can be inlined.
- When committing code on behalf of others use the `--author` option, e.g.
`git commit -a --author "Joe Coder <joe@coder.org>"` and `--signoff`.
- If your commit is addressing an issue, use the
[GitLab syntax](https://docs.gitlab.com/ce/user/project/issues/automatic_issue_closing.html)
to automatically close the issue when merging the commit with the upstream
repository:
```plain
Closes #1234
Fixes #1234
Closes: https://gitlab.gnome.org/GNOME/glib/issues/1234
```
- If you have a merge request with multiple commits and none of them
completely fixes an issue, you should add a reference to the issue in
the commit message, e.g. `Bug: #1234`, and use the automatic issue
closing syntax in the description of the merge request.
### Merge access to the GLib repository
GLib is part of the GNOME infrastructure. At the current time, any
person with write access to the GNOME repository can merge merge requests to
GLib. This is a good thing, in that it allows maintainership to be delegated
and shared as needed. However, GLib is a fairly large and complicated package
that many other things depend on, and which has platform specific behavior — so
to avoid unnecessary breakage, and to take advantage of the knowledge about GLib
that has been built up over the years, we’d like to ask people contributing to
GLib to follow a few rules:
0. Never push to the `master` branch, or any stable branches, directly; you
should always go through a merge request, to ensure that the code is
tested on the CI infrastructure at the very least. A merge request is
also the proper place to get a comprehensive code review from the core
developers of GLib.
0. Always get a code review, even for seemingly trivial changes.
0. Pay attention to the CI results. Merge requests cannot be merged until the
CI passes. If they consistently fail, either something is wrong with the
change, or the CI tests need fixing — in either case, please bring this to
the attention of a core developer rather than overriding the CI.
If you have been contributing to GLib for a while and you don’t have commit
access to the repository, you may ask to obtain it following the [GNOME account
process](https://wiki.gnome.org/AccountsTeam/NewAccounts).

22
OAT.xml
View File

@ -59,14 +59,30 @@ Note:If the text contains special characters, please escape them according to th
<licensefile>COPYING</licensefile>
<policylist>
<policy name="projectPolicy" desc="">
<policyitem type="license" name="LGPLStyleLicense" path="install.sh" rule="may" group="defaultGroup" filefilter="defaultPolicyFilter" desc="License Header Invalid, not linked"/>
<policyitem type="license" name="LGPL-2.1+" path="COPYING" rule="may" group="defaultGroup" filefilter="defaultPolicyFilter" desc="License File"/>
<policyitem type="license" name="NoLicenseHeader" path="BUILD.gn" rule="may" group="defaultGroup" filefilter="defaultPolicyFilter" desc="GN file"/>
<policyitem type="license" name="NoLicenseHeader" path="README.*" rule="may" group="defaultGroup" filefilter="defaultPolicyFilter" desc="README"/>
<policyitem type="license" name="NoLicenseHeader" path=".dir-locals.el" rule="may" group="defaultGroup" filefilter="defaultPolicyFilter" desc="License Header Invalid"/>
<policyitem type="license" name="InvalidLicense" path="glib2.spec" rule="may" group="defaultGroup" desc="The files involved in compilation are the InvalidLicense protocol.They are used in dynamic link mode."/>
<policyitem type="copyright" name="NULL" path=".dir-locals.el" rule="may" group="defaultGroup" filefilter="copyrightPolicyFilter" desc="Copyright Header Invalid, not linked"/>
<policyitem type="copyright" name="InvalidCopyright" path="BUILD.gn" rule="may" group="defaultGroup" filefilter="copyrightPolicyFilter" desc="GN file"/>
<policyitem type="copyright" name="NULL" path="glib2.spec" rule="may" group="defaultGroup" filefilter="copyrightPolicyFilter" desc="Copyright Header Invalid, not linked, not linked"/>
<policyitem type="copyright" name="NULL" path="README.*" rule="may" group="defaultGroup" filefilter="copyrightPolicyFilter" desc="README"/>
<policyitem type="copyright" name="InvalidCopyright" path="install.sh" rule="may" group="defaultGroup" filefilter="copyrightPolicyFilter" desc="Copyright Header Invalid, not linked"/>
</policy>
</policylist>
<filefilterlist>
<filefilter name="defaultPolicyFilter" desc="Filters for compatibility，license header policies">
<filteritem type="filepath" name=".*" desc="The files involved in compilation are the LGPL protocol.They are used in dynamic link mode."/>
<filefilter name="defaultPolicyFilter" desc="Filters for compatibility, license header policies">
<filteritem type="filepath" name="README.OpenSource" desc="OpenSource README, not linked."/>
<filteritem type="filepath" name="glib-2.68.1.tar.xz" desc="OpenEuler:glib2 code. The files involved in compilation are the LGPL protocol.They are used in dynamic link mode."/>
</filefilter>
<filefilter name="binaryFileTypePolicyFilter" desc="Filters for binary file policies">
<filteritem type="filepath" name=".*" desc="Resource, config and certification binary."/>
<filteritem type="filepath" name="BUILG.gn" desc="openEuler:glib2 build gn file."/>
<filteritem type="filepath" name="glib2.spec" desc="openEuler:glib2 spec."/>
<filteritem type="filepath" name="patch.tar.gz" desc="openEuler:glib2 origin patch."/>
<filteritem type="filepath" name="backport-patch.log" desc="openEuler:glib2 origin patch files name."/>
<filteritem type="filepath" name="glib-2.68.1.tar.xz" desc="openEuler:glib2 code."/>
</filefilter>
</filefilterlist>
</oatconfig>

1
README Normal file
View File

@ -0,0 +1 @@
See README.md

49
README.md Normal file
View File

@ -0,0 +1,49 @@
# 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)'
## How to report 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.
In the bug report 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.
## Patches
Patches should also be submitted as merge requests 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.

10
README.rationale Normal file
View File

@ -0,0 +1,10 @@
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.

1
README.win32 Normal file
View File

@ -0,0 +1 @@
See README.win32.md

233
README.win32.md Normal file
View File

@ -0,0 +1,233 @@
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.0 SDK in order to be built
successfully using Visual Studio, which means that building with Visual Studio
2008 or 2010 is possible only with a special setup and must be done in the
command line with Ninja. Please see
https://devblogs.microsoft.com/cppblog/using-the-windows-software-development-kit-sdk-for-windows-8-consumer-preview-with-visual-studio-2010/
for references; basically, assuming that your Windows 8.0 SDK is installed in
`C:\Program Files (x86)\Windows Kits\8.0` (`$(WIN8SDKDIR)` in short), you need
to ensure the following before invoking Meson to configure the build:
- Your `%INCLUDE%` must not include the Windows 7.0/7.1 SDK include directories,
and `$(WIN8SDKDIR)\include\um`, `$(WIN8SDKDIR)\include\um\share` and
`$(WIN8SDKDIR)\include\winrt` (in this order) must be before your stock
Visual Studio 2008/2010 header directories. If you have the DirectX SDK installed,
you should remove its include directory from your `%INCLUDE%` as well.
- You must replace the Windows 7.0/7.1 SDK library directory in `%LIB%` with the
Windows 8.0 SDK library directory, i.e. `$(WIN8SDKDIR)\lib\win8\um\[x86|x64]`.
If you have the DirectX SDK installed, you should remove its library directory
from your `%INCLUDE%` as well.
- You must replace the Windows 7.0/7.1 SDK tools directory from your `%PATH%` with
the Windows 8.0 SDK tools directory, i.e. `$(WIN8SDKDIR)\bin\[x86|x64]`.
If you have the DirectX SDK installed, you should remove its utility directory
from your `%PATH%` as well.
The Windows 8.0 SDK headers may contain an `roapi.h` that cannot be used under plain
C, so to remedy that, change the following lines (around lines 55-57):
```
// RegisterActivationFactory/RevokeActivationFactory registration cookie
typedef struct {} *RO_REGISTRATION_COOKIE;
// RegisterActivationFactory/DllGetActivationFactory callback
```
to
```
// RegisterActivationFactory/RevokeActivationFactory registration cookie
#ifdef __cplusplus
typedef struct {} *RO_REGISTRATION_COOKIE;
#else
typedef struct _RO_REGISTRATION_COOKIE *RO_REGISTRATION_COOKIE; /* make this header includable in C files */
#endif
// RegisterActivationFactory/DllGetActivationFactory callback
```
This follows what is done in the Windows 8.1 SDK, which contains an `roapi.h`
that is usable under plain C. Please note that you might need to copy that file
into a location that is in your `%INCLUDE%` which precedes the include path for the
Windows 8.0 SDK headers, if you do not have administrative privileges.
### Visual Studio 2008 hacks
- You need to run the following lines from your build directory, to embed the
manifests that are generated during the build, assuming the built binaries
are installed to `$(PREFIX)`, after a successful build/installation:
```cmd
> for /r %f in (*.dll.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f (PREFIX)\bin\%~nf;2
> for /r %f in (*.exe.manifest) do if exist $(PREFIX)\bin\%~nf mt /manifest %f (PREFIX)\bin\%~nf;1
```
- If building for amd64/x86_64/x64, sometimes the compilation of sources may seem to hang, which
is caused by an optimization issue in the 2008 x64 compiler. You need to use Task Manager to
remove all running instances of `cl.exe`, which will cause the build process to terminate. Update
the build flags of the sources that hang on compilation by changing its `"/O2"` flag to `"/O1"`
in `build.ninja`, and retry the build, where things should continue to build normally. At the
time of writing, this is needed for compiling `glib/gtestutils.c`, `gio/gsettings.c`,
`gio/gsettingsschema.c`, `glib/tests/fileutils.c` and `gio/tests/gsubprocess-testprog.c`

2
install.sh
View File

@ -19,6 +19,8 @@ find . ! -path "*/\.*" ! \( -name patch.tar.gz -o -name glib-2.68.1.tar.xz\
-o -name glib2.spec\
-o -name COPYING\
-o -name backport-patch.log\
-o -name "README*"\
-o -name CONTRIBUTING.md\
-o -name ".*" \)\
-prune -print -exec rm -rf {} \;
tar -zxvf patch.tar.gz