1 files changed, 15 insertions, 17 deletions

diff --git a/documentation/dev-manual/common-tasks.rst b/documentation/dev-manual/common-tasks.rst
index e870cdb545..0c267d5f48 100644
--- a/documentation/dev-manual/common-tasks.rst
+++ b/documentation/dev-manual/common-tasks.rst
@@ -938,7 +938,8 @@ a recipe and using :term:`EXTRA_IMAGE_FEATURES` from within your
 :term:`Build Directory`.
 
 To understand how these features work, the best reference is
-``meta/classes/image.bbclass``. This class lists out the available
+:ref:`meta/classes/image.bbclass <ref-classes-image>`.
+This class lists out the available
 :term:`IMAGE_FEATURES` of which most map to package groups while some, such
 as ``debug-tweaks`` and ``read-only-rootfs``, resolve as general
 configuration settings.
@@ -2113,7 +2114,7 @@ statement that essentially identifies itself as being able to provide
 
    PROVIDES += "${@ "virtual/kernel" if (d.getVar("KERNEL_PACKAGE_NAME") == "kernel") else "" }"
 
-Any recipe that inherits the ``kernel`` class is
+Any recipe that inherits the :ref:`kernel <ref-classes-kernel>` class is
 going to utilize a :term:`PROVIDES` statement that identifies that recipe as
 being able to provide the ``virtual/kernel`` item.
 
@@ -2459,7 +2460,7 @@ sometimes you have no choice.
 The easiest solution is to create a recipe that uses the
 :ref:`bin_package <ref-classes-bin-package>` class
 and to be sure that you are using default locations for build artifacts.
-In most cases, the ``bin_package`` class handles "skipping" the
+In most cases, the :ref:`bin_package <ref-classes-bin-package>` class handles "skipping" the
 configure and compile steps as well as sets things up to grab packages
 from the appropriate area. In particular, this class sets ``noexec`` on
 both the :ref:`ref-tasks-configure`
@@ -2467,7 +2468,7 @@ and :ref:`ref-tasks-compile` tasks,
 sets ``FILES:${PN}`` to "/" so that it picks up all files, and sets up a
 :ref:`ref-tasks-install` task, which
 effectively copies all files from ``${S}`` to ``${D}``. The
-``bin_package`` class works well when the files extracted into ``${S}``
+:ref:`bin_package <ref-classes-bin-package>` class works well when the files extracted into ``${S}``
 are already laid out in the way they should be laid out on the target.
 For more information on these variables, see the
 :term:`FILES`,
@@ -2492,7 +2493,7 @@ Reference Manual's variable glossary.
       section in the Yocto Project Overview and Concepts Manual for more
       information.
 
-If you cannot use the ``bin_package`` class, you need to be sure you are
+If you cannot use the :ref:`bin_package <ref-classes-bin-package>` class, you need to be sure you are
 doing the following:
 
 -  Create a recipe where the
@@ -2532,7 +2533,7 @@ doing the following:
 
 .. note::
 
-  If image prelinking is enabled (e.g. "image-prelink" is in :term:`USER_CLASSES`
+  If image prelinking is enabled (e.g. :ref:`image-prelink <ref-classes-image-prelink>` is in :term:`USER_CLASSES`
   which it is by default), prelink will change the binaries in the generated images
   and this often catches people out. Remove that class to ensure binaries are
   preserved exactly if that is necessary.
@@ -4454,19 +4455,16 @@ Follow these steps to build your target using the files in the downloads
 directory:
 
 1. *Using Local Files Only:* Inside your ``local.conf`` file, add the
-   :term:`SOURCE_MIRROR_URL`
-   variable, inherit the
-   :ref:`own-mirrors <ref-classes-own-mirrors>`
-   class, and use the
-   :term:`BB_NO_NETWORK`
-   variable to your ``local.conf``.
+   :term:`SOURCE_MIRROR_URL` variable, inherit the
+   :ref:`own-mirrors <ref-classes-own-mirrors>` class, and use the
+   :term:`BB_NO_NETWORK` variable to your ``local.conf``.
    ::
 
       SOURCE_MIRROR_URL ?= "file:///home/your-download-dir/"
       INHERIT += "own-mirrors"
       BB_NO_NETWORK = "1"
 
-   The :term:`SOURCE_MIRROR_URL` and ``own-mirror``
+   The :term:`SOURCE_MIRROR_URL` and :ref:`own-mirrors <ref-classes-own-mirrors>`
    class set up the system to use the downloads directory as your "own
    mirror". Using the :term:`BB_NO_NETWORK` variable makes sure that
    BitBake's fetching process in step 3 stays local, which means files
@@ -4751,7 +4749,8 @@ done using the
 Eventually, all recipes will be covered and this list will not be
 needed.
 
-For the most part, the Multilib class extension works automatically to
+For the most part, the :ref:`Multilib <ref-classes-multilib*>`
+class extension works automatically to
 extend the package name from ``${PN}`` to ``${MLPREFIX}${PN}``, where
 :term:`MLPREFIX` is the particular multilib (e.g. "lib32-" or "lib64-").
 Standard variables such as
@@ -4763,8 +4762,7 @@ Standard variables such as
 :term:`PACKAGES_DYNAMIC` are
 automatically extended by the system. If you are extending any manual
 code in the recipe, you can use the ``${MLPREFIX}`` variable to ensure
-those names are extended correctly. This automatic extension code
-resides in ``multilib.bbclass``.
+those names are extended correctly.
 
 Using Multilib
 ~~~~~~~~~~~~~~
@@ -10993,7 +10991,7 @@ accidental release of proprietary software. The Yocto Project provides
 an :ref:`archiver <ref-classes-archiver>` class to
 help avoid some of these concerns.
 
-Before you employ :term:`DL_DIR` or the ``archiver`` class, you need to
+Before you employ :term:`DL_DIR` or the :ref:`archiver <ref-classes-archiver>` class, you need to
 decide how you choose to provide source. The source ``archiver`` class
 can generate tarballs and SRPMs and can create them with various levels
 of compliance in mind.