diff options
Diffstat (limited to 'poky/documentation/test-manual')
3 files changed, 17 insertions, 1 deletions
diff --git a/poky/documentation/test-manual/reproducible-builds.rst b/poky/documentation/test-manual/reproducible-builds.rst index e13583c0b..68fdf547b 100644 --- a/poky/documentation/test-manual/reproducible-builds.rst +++ b/poky/documentation/test-manual/reproducible-builds.rst @@ -68,6 +68,17 @@ things we do within the build system to ensure reproducibility include: - Filtering the tools available from the host's ``PATH`` to only a specific set of tools, set using the :term:`HOSTTOOLS` variable. +.. note:: + + Because of an open bug in GCC, using ``DISTRO_FEATURES:append = " lto"`` or + adding ``-flto`` (Link Time Optimization) to ``CFLAGS`` makes the resulting + binary non-reproducible, in that it depends on the full absolute build path + to ``recipe-sysroot-native``, so installing the Yocto Project in a different + directory results in a different binary. + + This issue is addressed by + :yocto_bugs:`bug 14481 - Programs built with -flto are not reproducible</show_bug.cgi?id=14481>`. + ========================================= Can we prove the project is reproducible? ========================================= diff --git a/poky/documentation/test-manual/understand-autobuilder.rst b/poky/documentation/test-manual/understand-autobuilder.rst index c158d9ce4..b6809ce7b 100644 --- a/poky/documentation/test-manual/understand-autobuilder.rst +++ b/poky/documentation/test-manual/understand-autobuilder.rst @@ -27,7 +27,7 @@ which looks like:: "TEMPLATE" : "arch-qemu", "step1" : { "extravars" : [ - "IMAGE_FSTYPES_append = ' wic wic.bmap'" + "IMAGE_FSTYPES:append = ' wic wic.bmap'" ] } }, diff --git a/poky/documentation/test-manual/yocto-project-compatible.rst b/poky/documentation/test-manual/yocto-project-compatible.rst index a7897469f..96c12ac08 100644 --- a/poky/documentation/test-manual/yocto-project-compatible.rst +++ b/poky/documentation/test-manual/yocto-project-compatible.rst @@ -115,6 +115,11 @@ Here are key best practices the program tries to encourage: user changes a configuration setting to activate the layer, by selecting a :term:`MACHINE`, a :term:`DISTRO` or a :term:`DISTRO_FEATURES` setting. +- Layers should be documenting where they don’t support normal "core" + functionality such as where debug symbols are disabled or missing, where + development headers and on-target library usage may not work or where + functionality like the SDK/eSDK would not be expected to work. + The project does test the compatibility status of the core project layers on its :doc:`Autobuilder </test-manual/understand-autobuilder>`. |