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 distributions:
38
39-  Ubuntu 18.04 (LTS)
40
41-  Ubuntu 20.04 (LTS)
42
43-  Ubuntu 22.04 (LTS)
44
45-  Fedora 34
46
47-  Fedora 35
48
49-  AlmaLinux 8.5
50
51-  Debian GNU/Linux 10.x (Buster)
52
53-  Debian GNU/Linux 11.x (Bullseye)
54
55-  OpenSUSE Leap 15.3
56
57.. note::
58
59   -  While the Yocto Project Team attempts to ensure all Yocto Project
60      releases are one hundred percent compatible with each officially
61      supported Linux distribution, you may still encounter problems
62      that happen only with a specific distribution.
63
64   -  Yocto Project releases are tested against the stable Linux
65      distributions in the above list. The Yocto Project should work
66      on other distributions but validation is not performed against
67      them.
68
69   -  In particular, the Yocto Project does not support and currently
70      has no plans to support rolling-releases or development
71      distributions due to their constantly changing nature. We welcome
72      patches and bug reports, but keep in mind that our priority is on
73      the supported platforms listed above.
74
75   -  If your Linux distribution is not in the above list, we recommend to
76      get the :term:`buildtools` or :term:`buildtools-extended` tarballs
77      containing the host tools required by your Yocto Project release,
78      typically by running ``scripts/install-buildtools`` as explained in
79      the ":ref:`system-requirements-buildtools`" section.
80
81   -  You may use Windows Subsystem For Linux v2 to set up a build host
82      using Windows 10 or later, or Windows Server 2019 or later, but validation
83      is not performed against build hosts using WSL 2.
84
85      See the
86      :ref:`dev-manual/start:setting up to use windows subsystem for linux (wsl 2)`
87      section in the Yocto Project Development Tasks Manual for more information.
88
89   -  If you encounter problems, please go to :yocto_bugs:`Yocto Project
90      Bugzilla <>` and submit a bug. We are
91      interested in hearing about your experience. For information on
92      how to submit a bug, see the Yocto Project
93      :yocto_wiki:`Bugzilla wiki page </Bugzilla_Configuration_and_Bug_Tracking>`
94      and the ":ref:`dev-manual/changes:submitting a defect against the yocto project`"
95      section in the Yocto Project Development Tasks Manual.
96
97
98Required Packages for the Build Host
99====================================
100
101The list of packages you need on the host development system can be
102large when covering all build scenarios using the Yocto Project. This
103section describes required packages according to Linux distribution and
104function.
105
106.. _ubuntu-packages:
107
108Ubuntu and Debian
109-----------------
110
111Here are the required packages by function given a
112supported Ubuntu or Debian Linux distribution:
113
114.. note::
115
116   -  If your build system has the ``oss4-dev`` package installed, you
117      might experience QEMU build failures due to the package installing
118      its own custom ``/usr/include/linux/soundcard.h`` on the Debian
119      system. If you run into this situation, try either of these solutions::
120
121         $ sudo apt build-dep qemu
122         $ sudo apt remove oss4-dev
123
124-  *Essentials:* Packages needed to build an image on a headless system::
125
126      $ sudo apt install &UBUNTU_HOST_PACKAGES_ESSENTIAL;
127
128-  *Documentation:* Packages needed if you are going to build out the
129   Yocto Project documentation manuals::
130
131      $ sudo apt install make python3-pip inkscape texlive-latex-extra
132      &PIP3_HOST_PACKAGES_DOC;
133
134Fedora Packages
135---------------
136
137Here are the required packages by function given a
138supported Fedora Linux distribution:
139
140-  *Essentials:* Packages needed to build an image for a headless
141   system::
142
143      $ sudo dnf install &FEDORA_HOST_PACKAGES_ESSENTIAL;
144
145-  *Documentation:* Packages needed if you are going to build out the
146   Yocto Project documentation manuals::
147
148      $ sudo dnf install make python3-pip which inkscape texlive-fncychap
149      &PIP3_HOST_PACKAGES_DOC;
150
151openSUSE Packages
152-----------------
153
154Here are the required packages by function given a
155supported openSUSE Linux distribution:
156
157-  *Essentials:* Packages needed to build an image for a headless
158   system::
159
160      $ sudo zypper install &OPENSUSE_HOST_PACKAGES_ESSENTIAL;
161
162-  *Documentation:* Packages needed if you are going to build out the
163   Yocto Project documentation manuals::
164
165      $ sudo zypper install make python3-pip which inkscape texlive-fncychap
166      &PIP3_HOST_PACKAGES_DOC;
167
168
169AlmaLinux-8 Packages
170--------------------
171
172Here are the required packages by function given a
173supported AlmaLinux-8 Linux distribution:
174
175-  *Essentials:* Packages needed to build an image for a headless
176   system::
177
178      $ sudo dnf install &CENTOS8_HOST_PACKAGES_ESSENTIAL;
179
180   .. note::
181
182      -  Extra Packages for Enterprise Linux (i.e. ``epel-release``) is
183         a collection of packages from Fedora built on RHEL/CentOS for
184         easy installation of packages not included in enterprise Linux
185         by default. You need to install these packages separately.
186
187      -  The ``PowerTools`` repo provides additional packages such as
188         ``rpcgen`` and ``texinfo``.
189
190      -  The ``makecache`` command consumes additional Metadata from
191         ``epel-release``.
192
193-  *Documentation:* Packages needed if you are going to build out the
194   Yocto Project documentation manuals::
195
196      $ sudo dnf install make python3-pip which inkscape texlive-fncychap
197      &PIP3_HOST_PACKAGES_DOC;
198
199.. _system-requirements-buildtools:
200
201Required Git, tar, Python, make and gcc Versions
202================================================
203
204In order to use the build system, your host development system must meet
205the following version requirements for Git, tar, and Python:
206
207-  Git &MIN_GIT_VERSION; or greater
208
209-  tar &MIN_TAR_VERSION; or greater
210
211-  Python &MIN_PYTHON_VERSION; or greater
212
213-  GNU make &MIN_MAKE_VERSION; or greater
214
215If your host development system does not meet all these requirements,
216you can resolve this by installing a :term:`buildtools` tarball that
217contains these tools. You can either download a pre-built tarball or
218use BitBake to build one.
219
220In addition, your host development system must meet the following
221version requirement for gcc:
222
223-  gcc &MIN_GCC_VERSION; or greater
224
225If your host development system does not meet this requirement, you can
226resolve this by installing a :term:`buildtools-extended` tarball that
227contains additional tools, the equivalent of the Debian/Ubuntu ``build-essential``
228package.
229
230For systems with a broken make version (e.g. make 4.2.1 without patches) but
231where the rest of the host tools are usable, you can use the :term:`buildtools-make`
232tarball instead.
233
234In the sections that follow, three different methods will be described for
235installing the :term:`buildtools`, :term:`buildtools-extended` or :term:`buildtools-make`
236toolset.
237
238Installing a Pre-Built ``buildtools`` Tarball with ``install-buildtools`` script
239--------------------------------------------------------------------------------
240
241The ``install-buildtools`` script is the easiest of the three methods by
242which you can get these tools. It downloads a pre-built :term:`buildtools`
243installer and automatically installs the tools for you:
244
245#. Execute the ``install-buildtools`` script. Here is an example::
246
247      $ cd poky
248      $ scripts/install-buildtools \
249        --without-extended-buildtools \
250        --base-url &YOCTO_DL_URL;/releases/yocto \
251        --release yocto-&DISTRO; \
252        --installer-version &DISTRO;
253
254   During execution, the :term:`buildtools` tarball will be downloaded, the
255   checksum of the download will be verified, the installer will be run
256   for you, and some basic checks will be run to make sure the
257   installation is functional.
258
259   To avoid the need of ``sudo`` privileges, the ``install-buildtools``
260   script will by default tell the installer to install in::
261
262      /path/to/poky/buildtools
263
264   If your host development system needs the additional tools provided
265   in the :term:`buildtools-extended` tarball, you can instead execute the
266   ``install-buildtools`` script with the default parameters::
267
268      $ cd poky
269      $ scripts/install-buildtools
270
271   Alternatively if your host development system has a broken ``make``
272   version such that you only need a known good version of ``make``,
273   you can use the ``--make-only`` option::
274
275      $ cd poky
276      $ scripts/install-buildtools --make-only
277
278#. Source the tools environment setup script by using a command like the
279   following::
280
281      $ source /path/to/poky/buildtools/environment-setup-x86_64-pokysdk-linux
282
283   After you have sourced the setup script, the tools are added to
284   ``PATH`` and any other environment variables required to run the
285   tools are initialized. The results are working versions versions of
286   Git, tar, Python and ``chrpath``. And in the case of the
287   :term:`buildtools-extended` tarball, additional working versions of tools
288   including ``gcc``, ``make`` and the other tools included in
289   ``packagegroup-core-buildessential``.
290
291Downloading a Pre-Built ``buildtools`` Tarball
292----------------------------------------------
293
294If you would prefer not to use the ``install-buildtools`` script, you can instead
295download and run a pre-built :term:`buildtools` installer yourself with the following
296steps:
297
298#. Go to :yocto_dl:`/releases/yocto/yocto-&DISTRO;/buildtools/`, locate and
299   download the ``.sh`` file corresponding to your host architecture
300   and to :term:`buildtools`, :term:`buildtools-extended` or :term:`buildtools-make`.
301
302#. Execute the installation script. Here is an example for the
303   traditional installer::
304
305      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
306
307   Here is an example for the extended installer::
308
309      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
310
311   An example for the make-only installer::
312
313      $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh
314
315   During execution, a prompt appears that allows you to choose the
316   installation directory. For example, you could choose the following:
317   ``/home/your-username/buildtools``
318
319#. As instructed by the installer script, you will have to source the tools
320   environment setup script::
321
322      $ source /home/your_username/buildtools/environment-setup-x86_64-pokysdk-linux
323
324   After you have sourced the setup script, the tools are added to
325   ``PATH`` and any other environment variables required to run the
326   tools are initialized. The results are working versions versions of
327   Git, tar, Python and ``chrpath``. And in the case of the
328   :term:`buildtools-extended` tarball, additional working versions of tools
329   including ``gcc``, ``make`` and the other tools included in
330   ``packagegroup-core-buildessential``.
331
332Building Your Own ``buildtools`` Tarball
333----------------------------------------
334
335Building and running your own :term:`buildtools` installer applies only when you
336have a build host that can already run BitBake. In this case, you use
337that machine to build the ``.sh`` file and then take steps to transfer
338and run it on a machine that does not meet the minimal Git, tar, and
339Python (or gcc) requirements.
340
341Here are the steps to take to build and run your own :term:`buildtools`
342installer:
343
344#. On the machine that is able to run BitBake, be sure you have set up
345   your build environment with the setup script
346   (:ref:`structure-core-script`).
347
348#. Run the BitBake command to build the tarball::
349
350      $ bitbake buildtools-tarball
351
352   or to build the extended tarball::
353
354      $ bitbake buildtools-extended-tarball
355
356   or to build the make-only tarball::
357
358      $ bitbake buildtools-make-tarball
359
360   .. note::
361
362      The :term:`SDKMACHINE` variable in your ``local.conf`` file determines
363      whether you build tools for a 32-bit or 64-bit system.
364
365   Once the build completes, you can find the ``.sh`` file that installs
366   the tools in the ``tmp/deploy/sdk`` subdirectory of the
367   :term:`Build Directory`. The installer file has the string
368   "buildtools" or "buildtools-extended" in the name.
369
370#. Transfer the ``.sh`` file from the build host to the machine that
371   does not meet the Git, tar, or Python (or gcc) requirements.
372
373#. On this machine, run the ``.sh`` file to install the tools. Here is an
374   example for the traditional installer::
375
376      $ sh ~/Downloads/x86_64-buildtools-nativesdk-standalone-&DISTRO;.sh
377
378   For the extended installer::
379
380      $ sh ~/Downloads/x86_64-buildtools-extended-nativesdk-standalone-&DISTRO;.sh
381
382   And for the make-only installer::
383
384      $ sh ~/Downloads/x86_64-buildtools-make-nativesdk-standalone-&DISTRO;.sh
385
386   During execution, a prompt appears that allows you to choose the
387   installation directory. For example, you could choose the following:
388   ``/home/your_username/buildtools``
389
390#. Source the tools environment setup script by using a command like the
391   following::
392
393      $ source /home/your_username/buildtools/environment-setup-x86_64-poky-linux
394
395   After you have sourced the setup script, the tools are added to
396   ``PATH`` and any other environment variables required to run the
397   tools are initialized. The results are working versions versions of
398   Git, tar, Python and ``chrpath``. And in the case of the
399   :term:`buildtools-extended` tarball, additional working versions of tools
400   including ``gcc``, ``make`` and the other tools included in
401   ``packagegroup-core-buildessential``.
402