1.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
2
3*******************
4System Requirements
5*******************
6
7Welcome to the Yocto Project Reference Manual. This manual provides
8reference information for the current release of the Yocto Project, and
9is most effectively used after you have an understanding of the basics
10of the Yocto Project. The manual is neither meant to be read as a
11starting point to the Yocto Project, nor read from start to finish.
12Rather, use this manual to find variable definitions, class
13descriptions, and so forth as needed during the course of using the
14Yocto Project.
15
16For introductory information on the Yocto Project, see the
17:yocto_home:`Yocto Project Website <>` and the
18":ref:`overview-manual/development-environment:the yocto project development environment`"
19chapter in the Yocto Project Overview and Concepts Manual.
20
21If you want to use the Yocto Project to quickly build an image without
22having to understand concepts, work through the
23:doc:`/brief-yoctoprojectqs/index` document. You can find "how-to"
24information in the :doc:`/dev-manual/index`. You can find Yocto Project overview
25and conceptual information in the :doc:`/overview-manual/index`.
26
27.. note::
28
29   For more information about the Yocto Project Documentation set, see
30   the :ref:`ref-manual/resources:links and related documentation` section.
31
32.. _detailed-supported-distros:
33
34Supported Linux Distributions
35=============================
36
37Currently, the Yocto Project is supported on the following
38distributions:
39
40-  Ubuntu 18.04 (LTS)
41
42-  Ubuntu 20.04 (LTS)
43
44-  Fedora 34
45
46-  Fedora 35
47
48-  AlmaLinux 8.5
49
50-  Debian GNU/Linux 10.x (Buster)
51
52-  Debian GNU/Linux 11.x (Bullseye)
53
54-  OpenSUSE Leap 15.3
55
56.. note::
57
58   -  While the Yocto Project Team attempts to ensure all Yocto Project
59      releases are one hundred percent compatible with each officially
60      supported Linux distribution, you may still encounter problems
61      that happen only with a specific distribution.
62
63   -  Yocto Project releases are tested against the stable Linux
64      distributions in the above list. The Yocto Project should work
65      on other distributions but validation is not performed against
66      them.
67
68   -  In particular, the Yocto Project does not support and currently
69      has no plans to support rolling-releases or development
70      distributions due to their constantly changing nature. We welcome
71      patches and bug reports, but keep in mind that our priority is on
72      the supported platforms listed below.
73
74   -  You may use Windows Subsystem For Linux v2 to set up a build host
75      using Windows 10, but validation is not performed against build
76      hosts using WSLv2.
77
78   -  The Yocto Project is not compatible with WSLv1, it is
79      compatible but not officially supported nor validated with
80      WSLv2, if you still decide to use WSL please upgrade to WSLv2.
81
82   -  If you encounter problems, please go to :yocto_bugs:`Yocto Project
83      Bugzilla <>` and submit a bug. We are
84      interested in hearing about your experience. For information on
85      how to submit a bug, see the Yocto Project
86      :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
87      and the ":ref:`dev-manual/common-tasks:submitting a defect against the yocto project`"
88      section in the Yocto Project Development Tasks Manual.
89
90
91Required Packages for the Build Host
92====================================
93
94The list of packages you need on the host development system can be
95large when covering all build scenarios using the Yocto Project. This
96section describes required packages according to Linux distribution and
97function.
98
99.. _ubuntu-packages:
100
101Ubuntu and Debian
102-----------------
103
104Here are the required packages by function given a
105supported Ubuntu or Debian Linux distribution:
106
107.. note::
108
109   -  If your build system has the ``oss4-dev`` package installed, you
110      might experience QEMU build failures due to the package installing
111      its own custom ``/usr/include/linux/soundcard.h`` on the Debian
112      system. If you run into this situation, try either of these solutions::
113
114         $ sudo apt build-dep qemu
115         $ sudo apt remove oss4-dev
116
117-  *Essentials:* Packages needed to build an image on a headless system::
118
119      $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
120
121-  *Documentation:* Packages needed if you are going to build out the
122   Yocto Project documentation manuals::
123
124      $ sudo apt install make python3-pip inkscape texlive-latex-extra
125      &PIP3_HOST_PACKAGES_DOC;
126
127Fedora Packages
128---------------
129
130Here are the required packages by function given a
131supported Fedora Linux distribution:
132
133-  *Essentials:* Packages needed to build an image for a headless
134   system::
135
136      $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
137
138-  *Documentation:* Packages needed if you are going to build out the
139   Yocto Project documentation manuals::
140
141      $ sudo dnf install make python3-pip which inkscape texlive-fncychap
142      &PIP3_HOST_PACKAGES_DOC;
143
144openSUSE Packages
145-----------------
146
147Here are the required packages by function given a
148supported openSUSE Linux distribution:
149
150-  *Essentials:* Packages needed to build an image for a headless
151   system::
152
153      $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
154
155-  *Documentation:* Packages needed if you are going to build out the
156   Yocto Project documentation manuals::
157
158      $ sudo zypper install make python3-pip which inkscape texlive-fncychap
159      &PIP3_HOST_PACKAGES_DOC;
160
161
162AlmaLinux-8 Packages
163--------------------
164
165Here are the required packages by function given a
166supported AlmaLinux-8 Linux distribution:
167
168-  *Essentials:* Packages needed to build an image for a headless
169   system::
170
171      $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL;
172
173   .. note::
174
175      -  Extra Packages for Enterprise Linux (i.e. ``epel-release``) is
176         a collection of packages from Fedora built on RHEL/CentOS for
177         easy installation of packages not included in enterprise Linux
178         by default. You need to install these packages separately.
179
180      -  The ``PowerTools`` repo provides additional packages such as
181         ``rpcgen`` and ``texinfo``.
182
183      -  The ``makecache`` command consumes additional Metadata from
184         ``epel-release``.
185
186-  *Documentation:* Packages needed if you are going to build out the
187   Yocto Project documentation manuals::
188
189      $ sudo dnf install make python3-pip which inkscape texlive-fncychap
190      &PIP3_HOST_PACKAGES_DOC;
191
192Required Git, tar, Python, make and gcc Versions
193================================================
194
195In order to use the build system, your host development system must meet
196the following version requirements for Git, tar, and Python:
197
198-  Git &MIN_GIT_VERSION; or greater
199
200-  tar &MIN_TAR_VERSION; or greater
201
202-  Python &MIN_PYTHON_VERSION; or greater
203
204-  GNU make &MIN_MAKE_VERSION; or greater
205
206If your host development system does not meet all these requirements,
207you can resolve this by installing a ``buildtools`` tarball that
208contains these tools. You can get the tarball one of two ways: download
209a pre-built tarball or use BitBake to build the tarball.
210
211In addition, your host development system must meet the following
212version requirement for gcc:
213
214-  gcc &MIN_GCC_VERSION; or greater
215
216If your host development system does not meet this requirement, you can
217resolve this by installing a ``buildtools-extended`` tarball that
218contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential``
219package.
220
221In the sections that follow, three different methods will be described for
222installing the ``buildtools`` or ``buildtools-extended`` toolset.
223
224Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script
225--------------------------------------------------------------------------------
226
227The ``install-buildtools`` script is the easiest of the three methods by
228which you can get these tools. It downloads a pre-built buildtools
229installer and automatically installs the tools for you:
230
2311. Execute the ``install-buildtools`` script. Here is an example::
232
233      $ cd poky
234      $ scripts/install-buildtools \
235        --without-extended-buildtools \
236        --base-url &YOCTO_DL_URL;/releases/yocto \
237        --release yocto-&DISTRO; \
238        --installer-version &DISTRO;
239
240   During execution, the buildtools tarball will be downloaded, the
241   checksum of the download will be verified, the installer will be run
242   for you, and some basic checks will be run to make sure the
243   installation is functional.
244
245   To avoid the need of ``sudo`` privileges, the ``install-buildtools``
246   script will by default tell the installer to install in::
247
248      /path/to/poky/buildtools
249
250   If your host development system needs the additional tools provided
251   in the ``buildtools-extended`` tarball, you can instead execute the
252   ``install-buildtools`` script with the default parameters::
253
254      $ cd poky
255      $ scripts/install-buildtools
256
2572. Source the tools environment setup script by using a command like the
258   following::
259
260      $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux
261
262   Of course, you need to supply your installation directory and be sure to
263   use the right file (i.e. i586 or x86_64).
264
265   After you have sourced the setup script, the tools are added to
266   ``PATH`` and any other environment variables required to run the
267   tools are initialized. The results are working versions versions of
268   Git, tar, Python and ``chrpath``. And in the case of the
269   ``buildtools-extended`` tarball, additional working versions of tools
270   including ``gcc``, ``make`` and the other tools included in
271   ``packagegroup-core-buildessential``.
272
273Downloading a Pre-Built ``buildtools`` Tarball
274----------------------------------------------
275
276If you would prefer not to use the ``install-buildtools`` script, you can instead
277download and run a pre-built buildtools installer yourself with the following
278steps:
279
2801. Locate and download the ``*.sh`` at :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/`
281
2822. Execute the installation script. Here is an example for the
283   traditional installer::
284
285      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
286
287   Here is an example for the extended installer::
288
289      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
290
291   During execution, a prompt appears that allows you to choose the
292   installation directory. For example, you could choose the following:
293   ``/home/your-username/buildtools``
294
2953. Source the tools environment setup script by using a command like the
296   following::
297
298      $ source /home/your_username/buildtools/environment-setup-i586-poky-linux
299
300   Of
301   course, you need to supply your installation directory and be sure to
302   use the right file (i.e. i585 or x86-64).
303
304   After you have sourced the setup script, the tools are added to
305   ``PATH`` and any other environment variables required to run the
306   tools are initialized. The results are working versions versions of
307   Git, tar, Python and ``chrpath``. And in the case of the
308   ``buildtools-extended`` tarball, additional working versions of tools
309   including ``gcc``, ``make`` and the other tools included in
310   ``packagegroup-core-buildessential``.
311
312Building Your Own ``buildtools`` Tarball
313----------------------------------------
314
315Building and running your own buildtools installer applies only when you
316have a build host that can already run BitBake. In this case, you use
317that machine to build the ``.sh`` file and then take steps to transfer
318and run it on a machine that does not meet the minimal Git, tar, and
319Python (or gcc) requirements.
320
321Here are the steps to take to build and run your own buildtools
322installer:
323
3241. On the machine that is able to run BitBake, be sure you have set up
325   your build environment with the setup script
326   (:ref:`structure-core-script`).
327
3282. Run the BitBake command to build the tarball::
329
330      $ bitbake buildtools-tarball
331
332   or run the BitBake command to build the extended tarball::
333
334      $ bitbake buildtools-extended-tarball
335
336   .. note::
337
338      The :term:`SDKMACHINE` variable in your ``local.conf`` file determines
339      whether you build tools for a 32-bit or 64-bit system.
340
341   Once the build completes, you can find the ``.sh`` file that installs
342   the tools in the ``tmp/deploy/sdk`` subdirectory of the
343   :term:`Build Directory`. The installer file has the string
344   "buildtools" (or "buildtools-extended") in the name.
345
3463. Transfer the ``.sh`` file from the build host to the machine that
347   does not meet the Git, tar, or Python (or gcc) requirements.
348
3494. On the machine that does not meet the requirements, run the ``.sh``
350   file to install the tools. Here is an example for the traditional
351   installer::
352
353      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
354
355   Here is an example for the extended installer::
356
357      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
358
359   During execution, a prompt appears that allows you to choose the
360   installation directory. For example, you could choose the following:
361   ``/home/your_username/buildtools``
362
3635. Source the tools environment setup script by using a command like the
364   following::
365
366      $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux
367
368   Of course, you need to supply your installation directory and be sure to
369   use the right file (i.e. i586 or x86_64).
370
371   After you have sourced the setup script, the tools are added to
372   ``PATH`` and any other environment variables required to run the
373   tools are initialized. The results are working versions versions of
374   Git, tar, Python and ``chrpath``. And in the case of the
375   ``buildtools-extended`` tarball, additional working versions of tools
376   including ``gcc``, ``make`` and the other tools included in
377   ``packagegroup-core-buildessential``.
378