Complete Yocto mirror with license table for TQMa6UL (2038-compliance)
- 264 license table entries with exact download URLs (224/264 resolved) - Complete sources/ directory with all BitBake recipes - Build configuration: tqma6ul-multi-mba6ulx, spaetzle (musl) - Full traceability for Softwarefreigabeantrag - GCC 13.4.0, Linux 6.6.102, U-Boot 2023.04, musl 1.2.4 - License distribution: GPL-2.0 (24), MIT (23), GPL-2.0+ (18), BSD-3 (16)
This commit is contained in:
Siggi (OpenClaw Agent)
497
sources/poky/documentation/ref-manual/faq.rst
Normal file
497
sources/poky/documentation/ref-manual/faq.rst
Normal file
@@ -0,0 +1,497 @@
|
||||
.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
|
||||
|
||||
***
|
||||
FAQ
|
||||
***
|
||||
|
||||
.. contents::
|
||||
|
||||
General questions
|
||||
=================
|
||||
|
||||
How does Poky differ from OpenEmbedded?
|
||||
---------------------------------------
|
||||
|
||||
The term ``Poky`` refers to the specific reference build
|
||||
system that the Yocto Project provides. Poky is based on
|
||||
:term:`OpenEmbedded-Core (OE-Core)` and :term:`BitBake`. Thus, the
|
||||
generic term used here for the build system is the "OpenEmbedded build
|
||||
system." Development in the Yocto Project using Poky is closely tied to
|
||||
OpenEmbedded, with changes always being merged to OE-Core or BitBake
|
||||
first before being pulled back into Poky. This practice benefits both
|
||||
projects immediately.
|
||||
|
||||
How can you claim Poky / OpenEmbedded-Core is stable?
|
||||
-----------------------------------------------------
|
||||
|
||||
There are three areas that help with stability;
|
||||
|
||||
- The Yocto Project team keeps :term:`OpenEmbedded-Core (OE-Core)` small and
|
||||
focused, containing around 830 recipes as opposed to the thousands
|
||||
available in other OpenEmbedded community layers. Keeping it small
|
||||
makes it easy to test and maintain.
|
||||
|
||||
- The Yocto Project team runs manual and automated tests using a small,
|
||||
fixed set of reference hardware as well as emulated targets.
|
||||
|
||||
- The Yocto Project uses an :yocto_ab:`autobuilder <>`, which provides
|
||||
continuous build and integration tests.
|
||||
|
||||
Are there any products built using the OpenEmbedded build system?
|
||||
-----------------------------------------------------------------
|
||||
|
||||
See :yocto_wiki:`Products that use the Yocto Project
|
||||
</Project_Users#Products_that_use_the_Yocto_Project>` in the Yocto Project
|
||||
Wiki. Don't hesitate to contribute to this page if you know other such
|
||||
products.
|
||||
|
||||
Why isn't systemd the default init system for OpenEmbedded-Core/Yocto Project or in Poky?
|
||||
-----------------------------------------------------------------------------------------
|
||||
|
||||
`systemd <https://systemd.io/>`__ is a desktop Linux init system with a specific
|
||||
focus that is not entirely aligned with a customisable "embedded" build
|
||||
system/environment.
|
||||
|
||||
It understandably mandates certain layouts and configurations which may
|
||||
or may not align with what the objectives and direction :term:`OpenEmbedded-Core
|
||||
(OE-Core)` or Yocto Project want to take. It doesn't support all of our targets.
|
||||
For example `musl <https://www.musl-libc.org/>`__ support in systemd is
|
||||
problematic.
|
||||
|
||||
If it were our default, we would have to align with all their choices
|
||||
and this doesn't make sense. It is therefore a configuration option and
|
||||
available to anyone where the design goals align. But we are clear it
|
||||
is not the only way to handle init.
|
||||
|
||||
Our automated testing includes it through the ``poky-altcfg`` :term:`DISTRO` and
|
||||
we don't really need it to be the default: it is tested, it works, and people
|
||||
can choose to use it.
|
||||
|
||||
Building environment
|
||||
====================
|
||||
|
||||
Missing dependencies on the development system?
|
||||
-----------------------------------------------
|
||||
|
||||
If your development system does not meet the required Git, tar, and
|
||||
Python versions, you can get the required tools on your host development
|
||||
system in different ways (i.e. building a tarball or downloading a
|
||||
tarball). See the ":ref:`ref-manual/system-requirements:required git, tar, python, make and gcc versions`"
|
||||
section for steps on how to update your build tools.
|
||||
|
||||
How does OpenEmbedded fetch source code? Will it work through a firewall or proxy server?
|
||||
-----------------------------------------------------------------------------------------
|
||||
|
||||
The way the build system obtains source code is highly
|
||||
configurable. You can setup the build system to get source code in most
|
||||
environments if HTTP transport is available.
|
||||
|
||||
When the build system searches for source code, it first tries the local
|
||||
download directory. If that location fails, Poky tries
|
||||
:term:`PREMIRRORS`, the upstream source, and then
|
||||
:term:`MIRRORS` in that order.
|
||||
|
||||
Assuming your distribution is "poky", the OpenEmbedded build system uses
|
||||
the Yocto Project source :term:`PREMIRRORS` by default for SCM-based
|
||||
sources, upstreams for normal tarballs, and then falls back to a number
|
||||
of other mirrors including the Yocto Project source mirror if those
|
||||
fail.
|
||||
|
||||
As an example, you could add a specific server for the build system to
|
||||
attempt before any others by adding something like the following to the
|
||||
``local.conf`` configuration file::
|
||||
|
||||
PREMIRRORS:prepend = "\
|
||||
git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
|
||||
ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
|
||||
http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
|
||||
https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
|
||||
|
||||
These changes cause the build system to intercept Git, FTP, HTTP, and
|
||||
HTTPS requests and direct them to the ``http://`` sources mirror. You
|
||||
can use ``file://`` URLs to point to local directories or network shares
|
||||
as well.
|
||||
|
||||
Another option is to set::
|
||||
|
||||
BB_NO_NETWORK = "1"
|
||||
|
||||
This statement tells BitBake to issue an error
|
||||
instead of trying to access the Internet. This technique is useful if
|
||||
you want to ensure code builds only from local sources.
|
||||
|
||||
Here is another technique::
|
||||
|
||||
BB_FETCH_PREMIRRORONLY = "1"
|
||||
|
||||
This statement limits the build system to pulling source from the
|
||||
:term:`PREMIRRORS` only. Again, this technique is useful for reproducing
|
||||
builds.
|
||||
|
||||
Here is yet another technique::
|
||||
|
||||
BB_GENERATE_MIRROR_TARBALLS = "1"
|
||||
|
||||
This statement tells the build system to generate mirror tarballs. This
|
||||
technique is useful if you want to create a mirror server. If not,
|
||||
however, the technique can simply waste time during the build.
|
||||
|
||||
Finally, consider an example where you are behind an HTTP-only firewall.
|
||||
You could make the following changes to the ``local.conf`` configuration
|
||||
file as long as the :term:`PREMIRRORS` server is current::
|
||||
|
||||
PREMIRRORS:prepend = "\
|
||||
git://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
|
||||
ftp://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
|
||||
http://.*/.* &YOCTO_DL_URL;/mirror/sources/ \
|
||||
https://.*/.* &YOCTO_DL_URL;/mirror/sources/"
|
||||
BB_FETCH_PREMIRRORONLY = "1"
|
||||
|
||||
These changes would cause the build system to successfully fetch source
|
||||
over HTTP and any network accesses to anything other than the
|
||||
:term:`PREMIRRORS` would fail.
|
||||
|
||||
Most source fetching by the OpenEmbedded build system is done by
|
||||
``wget`` and you therefore need to specify the proxy settings in a
|
||||
``.wgetrc`` file, which can be in your home directory if you are a
|
||||
single user or can be in ``/usr/local/etc/wgetrc`` as a global user
|
||||
file.
|
||||
|
||||
Here is the applicable code for setting various proxy types in the
|
||||
``.wgetrc`` file. By default, these settings are disabled with comments.
|
||||
To use them, remove the comments::
|
||||
|
||||
# You can set the default proxies for Wget to use for http, https, and ftp.
|
||||
# They will override the value in the environment.
|
||||
#https_proxy = http://proxy.yoyodyne.com:18023/
|
||||
#http_proxy = http://proxy.yoyodyne.com:18023/
|
||||
#ftp_proxy = http://proxy.yoyodyne.com:18023/
|
||||
|
||||
# If you do not want to use proxy at all, set this to off.
|
||||
#use_proxy = on
|
||||
|
||||
The build system also accepts ``http_proxy``, ``ftp_proxy``, ``https_proxy``,
|
||||
and ``all_proxy`` set as to standard shell environment variables to redirect
|
||||
requests through proxy servers.
|
||||
|
||||
The Yocto Project also includes a
|
||||
``meta-poky/conf/templates/default/site.conf.sample`` file that shows
|
||||
how to configure CVS and Git proxy servers if needed.
|
||||
|
||||
.. note::
|
||||
|
||||
You can find more information on the
|
||||
":yocto_wiki:`Working Behind a Network Proxy </Working_Behind_a_Network_Proxy>`"
|
||||
Wiki page.
|
||||
|
||||
Using the OpenEmbedded Build system
|
||||
===================================
|
||||
|
||||
How do I use an external toolchain?
|
||||
-----------------------------------
|
||||
|
||||
See the ":ref:`dev-manual/external-toolchain:optionally using an external toolchain`"
|
||||
section in the Development Task manual.
|
||||
|
||||
Why do I get chmod permission issues?
|
||||
-------------------------------------
|
||||
|
||||
If you see the error
|
||||
``chmod: XXXXX new permissions are r-xrwxrwx, not r-xr-xr-x``,
|
||||
you are probably running the build on an NTFS filesystem. Instead,
|
||||
run the build system on a partition with a modern Linux filesystem such as
|
||||
``ext4``, ``btrfs`` or ``xfs``.
|
||||
|
||||
I see many 404 errors trying to download sources. Is anything wrong?
|
||||
--------------------------------------------------------------------
|
||||
|
||||
Nothing is wrong. The OpenEmbedded build system checks any
|
||||
configured source mirrors before downloading from the upstream sources.
|
||||
The build system does this searching for both source archives and
|
||||
pre-checked out versions of SCM-managed software. These checks help in
|
||||
large installations because it can reduce load on the SCM servers
|
||||
themselves. This can also allow builds to continue to work if an
|
||||
upstream source disappears.
|
||||
|
||||
Why do I get random build failures?
|
||||
-----------------------------------
|
||||
|
||||
If the same build is failing in totally different and random
|
||||
ways, the most likely explanation is:
|
||||
|
||||
- The hardware you are running the build on has some problem.
|
||||
|
||||
- You are running the build under virtualization, in which case the
|
||||
virtualization probably has bugs.
|
||||
|
||||
The OpenEmbedded build system processes a massive amount of data that
|
||||
causes lots of network, disk and CPU activity and is sensitive to even
|
||||
single-bit failures in any of these areas. True random failures have
|
||||
always been traced back to hardware or virtualization issues.
|
||||
|
||||
Why does the build fail with ``iconv.h`` problems?
|
||||
--------------------------------------------------
|
||||
|
||||
When you try to build a native recipe, you may get an error message that
|
||||
indicates that GNU ``libiconv`` is not in use but ``iconv.h`` has been
|
||||
included from ``libiconv``::
|
||||
|
||||
#error GNU libiconv not in use but included iconv.h is from libiconv
|
||||
|
||||
When this happens, you need to check whether you have a previously
|
||||
installed version of the header file in ``/usr/local/include/``.
|
||||
If that's the case, you should either uninstall it or temporarily rename
|
||||
it and try the build again.
|
||||
|
||||
This issue is just a single manifestation of "system leakage" issues
|
||||
caused when the OpenEmbedded build system finds and uses previously
|
||||
installed files during a native build. This type of issue might not be
|
||||
limited to ``iconv.h``. Make sure that leakage cannot occur from
|
||||
``/usr/local/include`` and ``/opt`` locations.
|
||||
|
||||
Why don't other recipes find the files provided by my ``*-native`` recipe?
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
Files provided by your native recipe could be missing from the native
|
||||
sysroot, your recipe could also be installing to the wrong place, or you
|
||||
could be getting permission errors during the :ref:`ref-tasks-install`
|
||||
task in your recipe.
|
||||
|
||||
This situation happens when the build system used by a package does not
|
||||
recognize the environment variables supplied to it by :term:`BitBake`. The
|
||||
incident that prompted this FAQ entry involved a Makefile that used an
|
||||
environment variable named ``BINDIR`` instead of the more standard
|
||||
variable ``bindir``. The makefile's hardcoded default value of
|
||||
"/usr/bin" worked most of the time, but not for the recipe's ``-native``
|
||||
variant. For another example, permission errors might be caused by a
|
||||
Makefile that ignores ``DESTDIR`` or uses a different name for that
|
||||
environment variable. Check the build system of the package to see if
|
||||
these kinds of issues exist.
|
||||
|
||||
Can I get rid of build output so I can start over?
|
||||
--------------------------------------------------
|
||||
|
||||
Yes --- you can easily do this. When you use BitBake to build an
|
||||
image, all the build output goes into the directory created when you run
|
||||
the build environment setup script (i.e. :ref:`structure-core-script`).
|
||||
By default, this :term:`Build Directory` is named ``build`` but can be named
|
||||
anything you want.
|
||||
|
||||
Within the :term:`Build Directory`, is the ``tmp`` directory. To remove all the
|
||||
build output yet preserve any source code or downloaded files from
|
||||
previous builds, simply remove the ``tmp`` directory.
|
||||
|
||||
Why isn't there a way to append bbclass files like bbappend for recipes?
|
||||
------------------------------------------------------------------------
|
||||
|
||||
The Yocto Project has consciously chosen not to implement such functionality.
|
||||
Class code is designed to be shared and reused, and exposes some level of
|
||||
configuration to its users. We want to encourage people to share these changes
|
||||
so we can build the best classes.
|
||||
|
||||
If the ``append`` functionality was available for classes, our evidence and
|
||||
experience suggest that people would create their custom changes in their
|
||||
layer instead of sharing and discussing the issues and/or limitations they
|
||||
encountered. This would lead to bizarre class interactions when new layers are
|
||||
included. We therefore consciously choose to have a natural pressure to share
|
||||
class code improvements or fixes.
|
||||
|
||||
There are also technical considerations like which recipes a class append would
|
||||
apply to and how that would fit within the layer model. These are complications
|
||||
we think we can live without!
|
||||
|
||||
Customizing generated images
|
||||
============================
|
||||
|
||||
What does the OpenEmbedded build system produce as output?
|
||||
----------------------------------------------------------
|
||||
|
||||
Because you can use the same set of recipes to create output of
|
||||
various formats, the output of an OpenEmbedded build depends on how you
|
||||
start it. Usually, the output is a flashable image ready for the target
|
||||
device.
|
||||
|
||||
How do I make the Yocto Project support my board?
|
||||
-------------------------------------------------
|
||||
|
||||
Support for an additional board is added by creating a Board
|
||||
Support Package (BSP) layer for it. For more information on how to
|
||||
create a BSP layer, see the
|
||||
":ref:`dev-manual/layers:understanding and creating layers`"
|
||||
section in the Yocto Project Development Tasks Manual and the
|
||||
:doc:`/bsp-guide/index`.
|
||||
|
||||
Usually, if the board is not completely exotic, adding support in the
|
||||
Yocto Project is fairly straightforward.
|
||||
|
||||
How do I make the Yocto Project support my package?
|
||||
---------------------------------------------------
|
||||
|
||||
To add a package, you need to create a BitBake recipe. For
|
||||
information on how to create a BitBake recipe, see the
|
||||
":ref:`dev-manual/new-recipe:writing a new recipe`"
|
||||
section in the Yocto Project Development Tasks Manual.
|
||||
|
||||
What do I need to ship for license compliance?
|
||||
----------------------------------------------
|
||||
|
||||
This is a difficult question and you need to consult your lawyer
|
||||
for the answer for your specific case. It is worth bearing in mind that
|
||||
for GPL compliance, there needs to be enough information shipped to
|
||||
allow someone else to rebuild and produce the same end result you are
|
||||
shipping. This means sharing the source code, any patches applied to it,
|
||||
and also any configuration information about how that package was
|
||||
configured and built.
|
||||
|
||||
You can find more information on licensing in the
|
||||
":ref:`overview-manual/development-environment:licensing`"
|
||||
section in the Yocto Project Overview and Concepts Manual and also in the
|
||||
":ref:`dev-manual/licenses:maintaining open source license compliance during your product's lifecycle`"
|
||||
section in the Yocto Project Development Tasks Manual.
|
||||
|
||||
Do I have to make a full reflash after recompiling one package?
|
||||
---------------------------------------------------------------
|
||||
|
||||
The OpenEmbedded build system can build packages in various
|
||||
formats such as IPK for OPKG, Debian package (``.deb``), or RPM. You can
|
||||
then upgrade only the modified packages using the package tools on the device,
|
||||
much like on a desktop distribution such as Ubuntu or Fedora. However,
|
||||
package management on the target is entirely optional.
|
||||
|
||||
How to prevent my package from being marked as machine specific?
|
||||
----------------------------------------------------------------
|
||||
|
||||
If you have machine-specific data in a package for one machine only
|
||||
but the package is being marked as machine-specific in all cases,
|
||||
you can set :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH` = "0" in the ``.bb`` file.
|
||||
However, but make sure the package is manually marked as machine-specific for the
|
||||
case that needs it. The code that handles :term:`SRC_URI_OVERRIDES_PACKAGE_ARCH`
|
||||
is in the ``meta/classes-global/base.bbclass`` file.
|
||||
|
||||
What's the difference between ``target`` and ``target-native``?
|
||||
---------------------------------------------------------------
|
||||
|
||||
The ``*-native`` targets are designed to run on the system being
|
||||
used for the build. These are usually tools that are needed to assist
|
||||
the build in some way such as ``quilt-native``, which is used to apply
|
||||
patches. The non-native version is the one that runs on the target
|
||||
device.
|
||||
|
||||
Why do ``${bindir}`` and ``${libdir}`` have strange values for ``-native`` recipes?
|
||||
-----------------------------------------------------------------------------------
|
||||
|
||||
Executables and libraries might need to be used from a directory
|
||||
other than the directory into which they were initially installed.
|
||||
Complicating this situation is the fact that sometimes these executables
|
||||
and libraries are compiled with the expectation of being run from that
|
||||
initial installation target directory. If this is the case, moving them
|
||||
causes problems.
|
||||
|
||||
This scenario is a fundamental problem for package maintainers of
|
||||
mainstream Linux distributions as well as for the OpenEmbedded build
|
||||
system. As such, a well-established solution exists. Makefiles,
|
||||
Autotools configuration scripts, and other build systems are expected to
|
||||
respect environment variables such as ``bindir``, ``libdir``, and
|
||||
``sysconfdir`` that indicate where executables, libraries, and data
|
||||
reside when a program is actually run. They are also expected to respect
|
||||
a ``DESTDIR`` environment variable, which is prepended to all the other
|
||||
variables when the build system actually installs the files. It is
|
||||
understood that the program does not actually run from within
|
||||
``DESTDIR``.
|
||||
|
||||
When the OpenEmbedded build system uses a recipe to build a
|
||||
target-architecture program (i.e. one that is intended for inclusion on
|
||||
the image being built), that program eventually runs from the root file
|
||||
system of that image. Thus, the build system provides a value of
|
||||
"/usr/bin" for ``bindir``, a value of "/usr/lib" for ``libdir``, and so
|
||||
forth.
|
||||
|
||||
Meanwhile, ``DESTDIR`` is a path within the :term:`Build Directory`.
|
||||
However, when the recipe builds a native program (i.e. one that is
|
||||
intended to run on the build machine), that program is never installed
|
||||
directly to the build machine's root file system. Consequently, the build
|
||||
system uses paths within the Build Directory for ``DESTDIR``, ``bindir``
|
||||
and related variables. To better understand this, consider the following
|
||||
two paths (artificially broken across lines for readability) where the
|
||||
first is relatively normal and the second is not::
|
||||
|
||||
/home/maxtothemax/poky-bootchart2/build/tmp/work/i586-poky-linux/zlib/
|
||||
1.2.8-r0/sysroot-destdir/usr/bin
|
||||
|
||||
/home/maxtothemax/poky-bootchart2/build/tmp/work/x86_64-linux/
|
||||
zlib-native/1.2.8-r0/sysroot-destdir/home/maxtothemax/poky-bootchart2/
|
||||
build/tmp/sysroots/x86_64-linux/usr/bin
|
||||
|
||||
Even if the paths look unusual, they both are correct --- the first for
|
||||
a target and the second for a native recipe. These paths are a consequence
|
||||
of the ``DESTDIR`` mechanism and while they appear strange, they are correct
|
||||
and in practice very effective.
|
||||
|
||||
How do I create images with more free space?
|
||||
--------------------------------------------
|
||||
|
||||
By default, the OpenEmbedded build system creates images that are
|
||||
1.3 times the size of the populated root filesystem. To affect the image
|
||||
size, you need to set various configurations:
|
||||
|
||||
- *Image Size:* The OpenEmbedded build system uses the
|
||||
:term:`IMAGE_ROOTFS_SIZE` variable to define
|
||||
the size of the image in Kbytes. The build system determines the size
|
||||
by taking into account the initial root filesystem size before any
|
||||
modifications such as requested size for the image and any requested
|
||||
additional free disk space to be added to the image.
|
||||
|
||||
- *Overhead:* Use the
|
||||
:term:`IMAGE_OVERHEAD_FACTOR` variable
|
||||
to define the multiplier that the build system applies to the initial
|
||||
image size, which is 1.3 by default.
|
||||
|
||||
- *Additional Free Space:* Use the
|
||||
:term:`IMAGE_ROOTFS_EXTRA_SPACE`
|
||||
variable to add additional free space to the image. The build system
|
||||
adds this space to the image after it determines its
|
||||
:term:`IMAGE_ROOTFS_SIZE`.
|
||||
|
||||
Why aren't spaces in path names supported?
|
||||
------------------------------------------
|
||||
|
||||
The Yocto Project team has tried to do this before but too many
|
||||
of the tools the OpenEmbedded build system depends on, such as
|
||||
``autoconf``, break when they find spaces in pathnames. Until that
|
||||
situation changes, the team will not support spaces in pathnames.
|
||||
|
||||
I'm adding a binary in a recipe. Why is it different in the image?
|
||||
------------------------------------------------------------------
|
||||
|
||||
The first most obvious change is the system stripping debug symbols from
|
||||
it. Setting :term:`INHIBIT_PACKAGE_STRIP` to stop debug symbols being
|
||||
stripped and/or :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` to stop debug symbols
|
||||
being split into a separate file will ensure the binary is unchanged.
|
||||
|
||||
Issues on the running system
|
||||
============================
|
||||
|
||||
How do I disable the cursor on my touchscreen device?
|
||||
-----------------------------------------------------
|
||||
|
||||
You need to create a form factor file as described in the
|
||||
":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
|
||||
the Yocto Project Board Support Packages (BSP) Developer's Guide. Set
|
||||
the ``HAVE_TOUCHSCREEN`` variable equal to one as follows::
|
||||
|
||||
HAVE_TOUCHSCREEN=1
|
||||
|
||||
How to always bring up connected network interfaces?
|
||||
----------------------------------------------------
|
||||
|
||||
The default interfaces file provided by the netbase recipe does
|
||||
not automatically bring up network interfaces. Therefore, you will need
|
||||
to add a BSP-specific netbase that includes an interfaces file. See the
|
||||
":ref:`bsp-guide/bsp:miscellaneous bsp-specific recipe files`" section in
|
||||
the Yocto Project Board Support Packages (BSP) Developer's Guide for
|
||||
information on creating these types of miscellaneous recipe files.
|
||||
|
||||
For example, add the following files to your layer::
|
||||
|
||||
meta-MACHINE/recipes-bsp/netbase/netbase/MACHINE/interfaces
|
||||
meta-MACHINE/recipes-bsp/netbase/netbase_5.0.bbappend
|
||||
Reference in New Issue
Block a user