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