2020-02-28 18:36:05 +03:00
|
|
|
.. _Supported-build-platforms:
|
|
|
|
|
|
|
|
|
|
Supported build platforms
|
|
|
|
|
=========================
|
|
|
|
|
|
|
|
|
|
QEMU aims to support building and executing on multiple host OS
|
|
|
|
|
platforms. This appendix outlines which platforms are the major build
|
|
|
|
|
targets. These platforms are used as the basis for deciding upon the
|
|
|
|
|
minimum required versions of 3rd party software QEMU depends on. The
|
|
|
|
|
supported platforms are the targets for automated testing performed by
|
|
|
|
|
the project when patches are submitted for review, and tested before and
|
|
|
|
|
after merge.
|
|
|
|
|
|
|
|
|
|
If a platform is not listed here, it does not imply that QEMU won't
|
|
|
|
|
work. If an unlisted platform has comparable software versions to a
|
|
|
|
|
listed platform, there is every expectation that it will work. Bug
|
|
|
|
|
reports are welcome for problems encountered on unlisted platforms
|
|
|
|
|
unless they are clearly older vintage than what is described here.
|
|
|
|
|
|
|
|
|
|
Note that when considering software versions shipped in distros as
|
|
|
|
|
support targets, QEMU considers only the version number, and assumes the
|
|
|
|
|
features in that distro match the upstream release with the same
|
|
|
|
|
version. In other words, if a distro backports extra features to the
|
|
|
|
|
software in their distro, QEMU upstream code will not add explicit
|
|
|
|
|
support for those backports, unless the feature is auto-detectable in a
|
|
|
|
|
manner that works for the upstream releases too.
|
|
|
|
|
|
2020-09-17 18:50:47 +03:00
|
|
|
The `Repology`_ site is a useful resource to identify
|
2020-02-28 18:36:05 +03:00
|
|
|
currently shipped versions of software in various operating systems,
|
|
|
|
|
though it does not cover all distros listed below.
|
|
|
|
|
|
2021-08-23 16:28:03 +03:00
|
|
|
Supported host architectures
|
|
|
|
|
----------------------------
|
|
|
|
|
|
|
|
|
|
Those hosts are officially supported, with various accelerators:
|
|
|
|
|
|
|
|
|
|
.. list-table::
|
|
|
|
|
:header-rows: 1
|
|
|
|
|
|
|
|
|
|
* - CPU Architecture
|
|
|
|
|
- Accelerators
|
|
|
|
|
* - Arm
|
|
|
|
|
- kvm (64 bit only), tcg, xen
|
2024-10-27 16:07:01 +03:00
|
|
|
* - MIPS (64 bit little endian only)
|
2021-08-23 16:28:03 +03:00
|
|
|
- kvm, tcg
|
|
|
|
|
* - PPC
|
|
|
|
|
- kvm, tcg
|
|
|
|
|
* - RISC-V
|
2022-07-19 11:26:35 +03:00
|
|
|
- kvm, tcg
|
2021-08-23 16:28:03 +03:00
|
|
|
* - s390x
|
|
|
|
|
- kvm, tcg
|
|
|
|
|
* - SPARC
|
|
|
|
|
- tcg
|
|
|
|
|
* - x86
|
2023-06-24 01:52:29 +03:00
|
|
|
- hvf (64 bit only), kvm, nvmm, tcg, whpx (64 bit only), xen
|
2021-08-23 16:28:03 +03:00
|
|
|
|
2021-11-06 14:14:57 +03:00
|
|
|
Other host architectures are not supported. It is possible to build QEMU system
|
|
|
|
|
emulation on an unsupported host architecture using the configure
|
|
|
|
|
``--enable-tcg-interpreter`` option to enable the TCI support, but note that
|
|
|
|
|
this is very slow and is not recommended for normal use. QEMU user emulation
|
|
|
|
|
requires host-specific support for signal handling, therefore TCI won't help
|
|
|
|
|
on unsupported host architectures.
|
2021-08-23 16:28:03 +03:00
|
|
|
|
|
|
|
|
Non-supported architectures may be removed in the future following the
|
|
|
|
|
:ref:`deprecation process<Deprecated features>`.
|
|
|
|
|
|
2020-09-17 18:50:47 +03:00
|
|
|
Linux OS, macOS, FreeBSD, NetBSD, OpenBSD
|
|
|
|
|
-----------------------------------------
|
2020-02-28 18:36:05 +03:00
|
|
|
|
2023-02-23 22:32:57 +03:00
|
|
|
The project aims to support the most recent major version at all times for
|
|
|
|
|
up to five years after its initial release. Support
|
2020-09-17 18:50:47 +03:00
|
|
|
for the previous major version will be dropped 2 years after the new major
|
|
|
|
|
version is released or when the vendor itself drops support, whichever comes
|
|
|
|
|
first. In this context, third-party efforts to extend the lifetime of a distro
|
2022-04-20 19:03:11 +03:00
|
|
|
are not considered, even when they are endorsed by the vendor (eg. Debian LTS);
|
|
|
|
|
the same is true of repositories that contain packages backported from later
|
|
|
|
|
releases (e.g. Debian backports). Within each major release, only the most
|
|
|
|
|
recent minor release is considered.
|
2020-02-28 18:36:05 +03:00
|
|
|
|
2020-09-17 18:50:47 +03:00
|
|
|
For the purposes of identifying supported software versions available on Linux,
|
|
|
|
|
the project will look at CentOS, Debian, Fedora, openSUSE, RHEL, SLES and
|
|
|
|
|
Ubuntu LTS. Other distros will be assumed to ship similar software versions.
|
2020-02-28 18:36:05 +03:00
|
|
|
|
2020-09-17 18:50:47 +03:00
|
|
|
For FreeBSD and OpenBSD, decisions will be made based on the contents of the
|
|
|
|
|
respective ports repository, while NetBSD will use the pkgsrc repository.
|
2020-02-28 18:36:05 +03:00
|
|
|
|
2022-04-22 11:34:03 +03:00
|
|
|
For macOS, `Homebrew`_ will be used, although `MacPorts`_ is expected to carry
|
2020-09-17 18:50:47 +03:00
|
|
|
similar versions.
|
2020-02-28 18:36:05 +03:00
|
|
|
|
docs: build-platforms: refine requirements on Python build dependencies
Historically, the critical dependency for both building and running
QEMU has been the distro packages. Because QEMU is written in C and C's
package management has been tied to distros (at least if you do not want
to bundle libraries with the binary, otherwise I suppose you could use
something like conda or wrapdb), C dependencies of QEMU would target the
version that is shipped in relatively old but still commonly used distros.
For non-C libraries, however, the situation is different, as these
languages have their own package management tool (cpan, pip, gem, npm,
and so on). For some of these languages, the amount of dependencies
for even a simple program can easily balloon to the point that many
distros have given up on packaging non-C code. For this reason, it has
become increasingly normal for developers to download dependencies into
a self-contained local environment, instead of relying on distro packages.
Fortunately, this affects QEMU only at build time, as qemu.git does
not package non-C artifacts such as the qemu.qmp package; but still,
as we make more use of Python, we experience a clash between a support
policy that is written for the C world, and dependencies (both direct
and indirect) that increasingly do not care for the distro versions
and are quick at moving past Python runtime versions that are declared
end-of-life.
For example, Python 3.6 has been EOL'd since December 2021 and Meson 0.62
(released the following March) already dropped support for it. Yet,
Python 3.6 is the default version of the Python runtime for RHEL/CentOS
8 and SLE 15, respectively the penultimate and the most recent version
of two distros that QEMU would like to support. (It is also the version
used by Ubuntu 18.04, but QEMU stopped supporting it in April 2022).
There are good reasons to move forward with the deprecation of Python
3.6 in QEMU as well: completing the configure->meson switch (which
requires Meson 0.63), and making the QAPI generator fully typed (which
requires newer versions of not just mypy but also Python, due to PEP563).
Fortunately, these long-term support distros do include newer versions of
the Python runtime. However, these more recent runtimes only come with
a very small subset of the Python packages that the distro includes.
Because most dependencies are optional tests (avocado, mypy, flake8)
and Meson is bundled with QEMU, the most noticeably missing package is
Sphinx (and the readthedocs theme). There are four possibilities:
* we change the support policy and stop supporting CentOS 8 and SLE 15;
not a good idea since CentOS 8 is not an unreasonable distro for us to
want to continue to support
* we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being
supported. This is a possibility---but we may want to revise the support
policy anyway because SLE 16 has not even been released, so this would
mean delaying those desirable reasons for perhaps three years;
* we support Python 3.6 just for building documentation, i.e. we are
careful not to use Python 3.7+ features in our Sphinx extensions but are
free to use them elsewhere. Besides being more complicated to understand
for developers, this can be quite limiting; parts of the QAPI generator
run at sphinx-build time, which would exclude one of the areas which
would benefit from a newer version of the runtime;
* we only support Python 3.7+, which means CentOS 8 CI and users
have to either install Sphinx from pip or disable documentation.
This proposed update to the support policy chooses the last of these
possibilities. It does by modifying three aspects of the support
policy:
* it introduces different support periods for *native* vs. *non-native*
dependencies. Non-native dependencies are currently Python ones only,
and for simplicity the policy only mentions Python; however, the concept
generalizes to other languages with a well-known upstream package
manager, that users of older distributions can fetch dependencies from;
* it opens up the possibility of taking non-native dependencies from their
own package index instead of using the version in the distribution. The
wording right now is specific to dependencies that are only required at
build time. In the future we may have to refine it if, for example, parts
of QEMU will be written in Rust; in that case, crates would be handled
in a similar way to submodules and vendored in the release tarballs.
* it mentions specifically that optional build dependencies are excluded
from the platform policy. Tools such as mypy don't affect the ability
to build QEMU and move fast enough that distros cannot standardize on
a single version of them (for example RHEL9 does not package them at
all, nor does it run them at rpmbuild time). In other cases, such as
cross compilers, we have alternatives.
Right now, non-native dependencies have to be download manually by
running "pip" before "configure". In the future, it will be desirable
for configure to set up a virtual environment and download them in the
same way that it populates git submodules (but, in this case, without
vendoring them in the release tarballs).
Just like with submodules, this would make things easier for people
that can afford accessing the network in their build environment; the
option to populate the build environment manually would remain for
people whose build machines lack network access. The change to the
support policy neither requires nor forbids this future change.
[Thanks to Daniel P. Berrangé, Peter Maydell and others for discussions
that were copied or summarized in the above commit message]
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-02-17 15:09:56 +03:00
|
|
|
Some build dependencies may follow less conservative rules:
|
|
|
|
|
|
|
|
|
|
Python runtime
|
|
|
|
|
Distributions with long-term support often provide multiple versions
|
|
|
|
|
of the Python runtime. While QEMU will initially aim to support the
|
|
|
|
|
distribution's default runtime, it may later increase its minimum version
|
|
|
|
|
to any newer python that is available as an option from the vendor.
|
|
|
|
|
In this case, it will be necessary to use the ``--python`` command line
|
|
|
|
|
option of the ``configure`` script to point QEMU to a supported
|
|
|
|
|
version of the Python runtime.
|
|
|
|
|
|
Python: Drop support for Python 3.6
Python 3.6 was EOL 2021-12-31. Newer versions of upstream libraries have
begun dropping support for this version and it is becoming more
cumbersome to support. Avocado-framework and qemu.qmp each have their
own reasons for wanting to drop Python 3.6, but won't until QEMU does.
Versions of Python available in our supported build platforms as of today,
with optional versions available in parentheses:
openSUSE Leap 15.4: 3.6.15 (3.9.10, 3.10.2)
CentOS Stream 8: 3.6.8 (3.8.13, 3.9.16)
CentOS Stream 9: 3.9.13
Fedora 36: 3.10
Fedora 37: 3.11
Debian 11: 3.9.2
Alpine 3.14, 3.15: 3.9.16
Alpine 3.16, 3.17: 3.10.10
Ubuntu 20.04 LTS: 3.8.10
Ubuntu 22.04 LTS: 3.10.4
NetBSD 9.3: 3.9.13*
FreeBSD 12.4: 3.9.16
FreeBSD 13.1: 3.9.16
OpenBSD 7.2: 3.9.16
Note: Our VM tests install 3.9 explicitly for FreeBSD and 3.10 for
NetBSD; the default for "python" or "python3" in FreeBSD is
3.9.16. NetBSD does not appear to have a default meta-package, but
offers several options, the lowest of which is 3.7.15. "python39"
appears to be a pre-requisite to one of the other packages we request in
tests/vm/netbsd. pip, ensurepip and other Python essentials are
currently only available for Python 3.10 for NetBSD.
CentOS and OpenSUSE support parallel installation of multiple Python
interpreters, and binaries in /usr/bin will always use Python 3.6. However,
the newly introduced support for virtual environments ensures that all build
steps that execute QEMU Python code use a single interpreter.
Since it is safe to under our supported platform policy, bump our
minimum supported version of Python to 3.7.
Signed-off-by: John Snow <jsnow@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <20230511035435.734312-24-jsnow@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-05-11 06:54:31 +03:00
|
|
|
As of QEMU |version|, the minimum supported version of Python is 3.7.
|
docs: build-platforms: refine requirements on Python build dependencies
Historically, the critical dependency for both building and running
QEMU has been the distro packages. Because QEMU is written in C and C's
package management has been tied to distros (at least if you do not want
to bundle libraries with the binary, otherwise I suppose you could use
something like conda or wrapdb), C dependencies of QEMU would target the
version that is shipped in relatively old but still commonly used distros.
For non-C libraries, however, the situation is different, as these
languages have their own package management tool (cpan, pip, gem, npm,
and so on). For some of these languages, the amount of dependencies
for even a simple program can easily balloon to the point that many
distros have given up on packaging non-C code. For this reason, it has
become increasingly normal for developers to download dependencies into
a self-contained local environment, instead of relying on distro packages.
Fortunately, this affects QEMU only at build time, as qemu.git does
not package non-C artifacts such as the qemu.qmp package; but still,
as we make more use of Python, we experience a clash between a support
policy that is written for the C world, and dependencies (both direct
and indirect) that increasingly do not care for the distro versions
and are quick at moving past Python runtime versions that are declared
end-of-life.
For example, Python 3.6 has been EOL'd since December 2021 and Meson 0.62
(released the following March) already dropped support for it. Yet,
Python 3.6 is the default version of the Python runtime for RHEL/CentOS
8 and SLE 15, respectively the penultimate and the most recent version
of two distros that QEMU would like to support. (It is also the version
used by Ubuntu 18.04, but QEMU stopped supporting it in April 2022).
There are good reasons to move forward with the deprecation of Python
3.6 in QEMU as well: completing the configure->meson switch (which
requires Meson 0.63), and making the QAPI generator fully typed (which
requires newer versions of not just mypy but also Python, due to PEP563).
Fortunately, these long-term support distros do include newer versions of
the Python runtime. However, these more recent runtimes only come with
a very small subset of the Python packages that the distro includes.
Because most dependencies are optional tests (avocado, mypy, flake8)
and Meson is bundled with QEMU, the most noticeably missing package is
Sphinx (and the readthedocs theme). There are four possibilities:
* we change the support policy and stop supporting CentOS 8 and SLE 15;
not a good idea since CentOS 8 is not an unreasonable distro for us to
want to continue to support
* we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being
supported. This is a possibility---but we may want to revise the support
policy anyway because SLE 16 has not even been released, so this would
mean delaying those desirable reasons for perhaps three years;
* we support Python 3.6 just for building documentation, i.e. we are
careful not to use Python 3.7+ features in our Sphinx extensions but are
free to use them elsewhere. Besides being more complicated to understand
for developers, this can be quite limiting; parts of the QAPI generator
run at sphinx-build time, which would exclude one of the areas which
would benefit from a newer version of the runtime;
* we only support Python 3.7+, which means CentOS 8 CI and users
have to either install Sphinx from pip or disable documentation.
This proposed update to the support policy chooses the last of these
possibilities. It does by modifying three aspects of the support
policy:
* it introduces different support periods for *native* vs. *non-native*
dependencies. Non-native dependencies are currently Python ones only,
and for simplicity the policy only mentions Python; however, the concept
generalizes to other languages with a well-known upstream package
manager, that users of older distributions can fetch dependencies from;
* it opens up the possibility of taking non-native dependencies from their
own package index instead of using the version in the distribution. The
wording right now is specific to dependencies that are only required at
build time. In the future we may have to refine it if, for example, parts
of QEMU will be written in Rust; in that case, crates would be handled
in a similar way to submodules and vendored in the release tarballs.
* it mentions specifically that optional build dependencies are excluded
from the platform policy. Tools such as mypy don't affect the ability
to build QEMU and move fast enough that distros cannot standardize on
a single version of them (for example RHEL9 does not package them at
all, nor does it run them at rpmbuild time). In other cases, such as
cross compilers, we have alternatives.
Right now, non-native dependencies have to be download manually by
running "pip" before "configure". In the future, it will be desirable
for configure to set up a virtual environment and download them in the
same way that it populates git submodules (but, in this case, without
vendoring them in the release tarballs).
Just like with submodules, this would make things easier for people
that can afford accessing the network in their build environment; the
option to populate the build environment manually would remain for
people whose build machines lack network access. The change to the
support policy neither requires nor forbids this future change.
[Thanks to Daniel P. Berrangé, Peter Maydell and others for discussions
that were copied or summarized in the above commit message]
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-02-17 15:09:56 +03:00
|
|
|
|
|
|
|
|
Python build dependencies
|
|
|
|
|
Some of QEMU's build dependencies are written in Python. Usually these
|
|
|
|
|
are only packaged by distributions for the default Python runtime.
|
|
|
|
|
If QEMU bumps its minimum Python version and a non-default runtime is
|
|
|
|
|
required, it may be necessary to fetch python modules from the Python
|
|
|
|
|
Package Index (PyPI) via ``pip``, in order to build QEMU.
|
|
|
|
|
|
2024-10-15 16:00:41 +03:00
|
|
|
Rust build dependencies
|
|
|
|
|
QEMU is generally conservative in adding new Rust dependencies, and all
|
|
|
|
|
of them are included in the distributed tarballs. One exception is the
|
|
|
|
|
bindgen tool, which is too big to package and distribute. The minimum
|
|
|
|
|
supported version of bindgen is 0.60.x. For distributions that do not
|
|
|
|
|
include bindgen or have an older version, it is recommended to install
|
|
|
|
|
a newer version using ``cargo install bindgen-cli``.
|
|
|
|
|
|
|
|
|
|
Developers may want to use Cargo-based tools in the QEMU source tree;
|
|
|
|
|
this requires Cargo 1.74.0. Note that Cargo is not required in order
|
|
|
|
|
to build QEMU.
|
|
|
|
|
|
docs: build-platforms: refine requirements on Python build dependencies
Historically, the critical dependency for both building and running
QEMU has been the distro packages. Because QEMU is written in C and C's
package management has been tied to distros (at least if you do not want
to bundle libraries with the binary, otherwise I suppose you could use
something like conda or wrapdb), C dependencies of QEMU would target the
version that is shipped in relatively old but still commonly used distros.
For non-C libraries, however, the situation is different, as these
languages have their own package management tool (cpan, pip, gem, npm,
and so on). For some of these languages, the amount of dependencies
for even a simple program can easily balloon to the point that many
distros have given up on packaging non-C code. For this reason, it has
become increasingly normal for developers to download dependencies into
a self-contained local environment, instead of relying on distro packages.
Fortunately, this affects QEMU only at build time, as qemu.git does
not package non-C artifacts such as the qemu.qmp package; but still,
as we make more use of Python, we experience a clash between a support
policy that is written for the C world, and dependencies (both direct
and indirect) that increasingly do not care for the distro versions
and are quick at moving past Python runtime versions that are declared
end-of-life.
For example, Python 3.6 has been EOL'd since December 2021 and Meson 0.62
(released the following March) already dropped support for it. Yet,
Python 3.6 is the default version of the Python runtime for RHEL/CentOS
8 and SLE 15, respectively the penultimate and the most recent version
of two distros that QEMU would like to support. (It is also the version
used by Ubuntu 18.04, but QEMU stopped supporting it in April 2022).
There are good reasons to move forward with the deprecation of Python
3.6 in QEMU as well: completing the configure->meson switch (which
requires Meson 0.63), and making the QAPI generator fully typed (which
requires newer versions of not just mypy but also Python, due to PEP563).
Fortunately, these long-term support distros do include newer versions of
the Python runtime. However, these more recent runtimes only come with
a very small subset of the Python packages that the distro includes.
Because most dependencies are optional tests (avocado, mypy, flake8)
and Meson is bundled with QEMU, the most noticeably missing package is
Sphinx (and the readthedocs theme). There are four possibilities:
* we change the support policy and stop supporting CentOS 8 and SLE 15;
not a good idea since CentOS 8 is not an unreasonable distro for us to
want to continue to support
* we keep supporting Python 3.6 until CentOS 8 and SLE 15 stop being
supported. This is a possibility---but we may want to revise the support
policy anyway because SLE 16 has not even been released, so this would
mean delaying those desirable reasons for perhaps three years;
* we support Python 3.6 just for building documentation, i.e. we are
careful not to use Python 3.7+ features in our Sphinx extensions but are
free to use them elsewhere. Besides being more complicated to understand
for developers, this can be quite limiting; parts of the QAPI generator
run at sphinx-build time, which would exclude one of the areas which
would benefit from a newer version of the runtime;
* we only support Python 3.7+, which means CentOS 8 CI and users
have to either install Sphinx from pip or disable documentation.
This proposed update to the support policy chooses the last of these
possibilities. It does by modifying three aspects of the support
policy:
* it introduces different support periods for *native* vs. *non-native*
dependencies. Non-native dependencies are currently Python ones only,
and for simplicity the policy only mentions Python; however, the concept
generalizes to other languages with a well-known upstream package
manager, that users of older distributions can fetch dependencies from;
* it opens up the possibility of taking non-native dependencies from their
own package index instead of using the version in the distribution. The
wording right now is specific to dependencies that are only required at
build time. In the future we may have to refine it if, for example, parts
of QEMU will be written in Rust; in that case, crates would be handled
in a similar way to submodules and vendored in the release tarballs.
* it mentions specifically that optional build dependencies are excluded
from the platform policy. Tools such as mypy don't affect the ability
to build QEMU and move fast enough that distros cannot standardize on
a single version of them (for example RHEL9 does not package them at
all, nor does it run them at rpmbuild time). In other cases, such as
cross compilers, we have alternatives.
Right now, non-native dependencies have to be download manually by
running "pip" before "configure". In the future, it will be desirable
for configure to set up a virtual environment and download them in the
same way that it populates git submodules (but, in this case, without
vendoring them in the release tarballs).
Just like with submodules, this would make things easier for people
that can afford accessing the network in their build environment; the
option to populate the build environment manually would remain for
people whose build machines lack network access. The change to the
support policy neither requires nor forbids this future change.
[Thanks to Daniel P. Berrangé, Peter Maydell and others for discussions
that were copied or summarized in the above commit message]
Cc: Markus Armbruster <armbru@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>
Cc: John Snow <jsnow@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2023-02-17 15:09:56 +03:00
|
|
|
Optional build dependencies
|
|
|
|
|
Build components whose absence does not affect the ability to build
|
|
|
|
|
QEMU may not be available in distros, or may be too old for QEMU's
|
|
|
|
|
requirements. Many of these, such as the Avocado testing framework
|
|
|
|
|
or various linters, are written in Python and therefore can also
|
|
|
|
|
be installed using ``pip``. Cross compilers are another example
|
|
|
|
|
of optional build-time dependency; in this case it is possible to
|
|
|
|
|
download them from repositories such as EPEL, to use container-based
|
|
|
|
|
cross compilation using ``docker`` or ``podman``, or to use pre-built
|
|
|
|
|
binaries distributed with QEMU.
|
|
|
|
|
|
|
|
|
|
|
2020-09-17 18:50:47 +03:00
|
|
|
Windows
|
2020-02-28 18:36:05 +03:00
|
|
|
-------
|
|
|
|
|
|
2022-05-13 09:39:58 +03:00
|
|
|
The project aims to support the two most recent versions of Windows that are
|
|
|
|
|
still supported by the vendor. The minimum Windows API that is currently
|
2022-06-24 17:50:37 +03:00
|
|
|
targeted is "Windows 8", so theoretically the QEMU binaries can still be run
|
2022-05-13 09:39:58 +03:00
|
|
|
on older versions of Windows, too. However, such old versions of Windows are
|
|
|
|
|
not tested anymore, so it is recommended to use one of the latest versions of
|
|
|
|
|
Windows instead.
|
|
|
|
|
|
|
|
|
|
The project supports building QEMU with current versions of the MinGW
|
2022-07-19 16:50:14 +03:00
|
|
|
toolchain, either hosted on Linux (Debian/Fedora) or via `MSYS2`_ on Windows.
|
|
|
|
|
A more recent Windows version is always preferred as it is less likely to have
|
|
|
|
|
problems with building via MSYS2. The building process of QEMU involves some
|
|
|
|
|
Python scripts that call os.symlink() which needs special attention for the
|
|
|
|
|
build process to successfully complete. On newer versions of Windows 10,
|
|
|
|
|
unprivileged accounts can create symlinks if Developer Mode is enabled.
|
|
|
|
|
When Developer Mode is not available/enabled, the SeCreateSymbolicLinkPrivilege
|
|
|
|
|
privilege is required, or the process must be run as an administrator.
|
2020-02-28 18:36:05 +03:00
|
|
|
|
2024-02-22 16:09:18 +03:00
|
|
|
Only 64-bit Windows is supported.
|
|
|
|
|
|
2022-04-22 11:34:03 +03:00
|
|
|
.. _Homebrew: https://brew.sh/
|
2020-09-17 18:50:47 +03:00
|
|
|
.. _MacPorts: https://www.macports.org/
|
2022-07-19 16:50:14 +03:00
|
|
|
.. _MSYS2: https://www.msys2.org/
|
2020-09-17 18:50:47 +03:00
|
|
|
.. _Repology: https://repology.org/
|