5 files changed, 20 insertions, 20 deletions
diff --git a/doc/daily_work.rst b/doc/daily_work.rst
index 0490e9030..2dc9c4c97 100644
@@ -129,7 +129,7 @@ hints on how to discover these dependencies.
Dependencies on Shared Libraries
-Getting the missed shared library for example at runtime is something
+Getting the missed shared library for example at run-time is something
easily done: The dynamic linker prints the missing library to the
@@ -158,7 +158,7 @@ Dependencies on other Resources
Sometimes a binary fails to run due to missing files, directories or
device nodes. Often the error message (if any) which the binary creates
in this case is ambiguous. Here the ``strace`` tool can help us, namely
-to observe the binary at runtime. ``strace`` shows all the system calls
+to observe the binary at run-time. ``strace`` shows all the system calls
the binary or its shared libraries are performing.
``strace`` is one of the target debugging tools which PTXdist provides
@@ -217,7 +217,7 @@ run ELF binaries for other architectures than our build host is.
Running an Application made for a different Architecture
-PTXdist creates a fully working root filesystem with all runtime
+PTXdist creates a fully working root filesystem with all run-time
components in ``root/``. Lets assume we made a PTXdist based project for
a CPU. Part of this project is our application ``myapp`` we are
currently working on. PTXdist builds the root filesystem and also
@@ -314,9 +314,9 @@ Now we can step through our application by using the commands *step*,
*next*, *stepi*, *nexti*, *until* and so on.
.. note:: It might be impossible for GDB to find debug symbols for
- components like the main C runtime library. In this case they where
+ components like the main C run-time library. In this case they where
stripped while building the toolchain. There is a switch in the
- OSELAS.Toolchain menu to keep the debug symbols also for the C runtime
+ OSELAS.Toolchain menu to keep the debug symbols also for the C run-time
library. But be warned: This will enlarge the OSELAS.Toolchain
installation on your harddisk! When the toolchain was built with the
debug symbols kept, it will be also possible for GDB to debug C library
diff --git a/doc/dev_manual.rst b/doc/dev_manual.rst
index e89857549..cbbb1dd1c 100644
@@ -7,7 +7,7 @@ This chapter shows all (or most) of the details of how PTXdist works.
- how patching works
-- where is PTXdist fetching a package’s runtime configuration files
+- where is PTXdist fetching a package’s run-time configuration files
- how to control a package’s build stages
@@ -26,7 +26,7 @@ Rule Files
When building a single package, PTXdist needs the information on how to
handle the package, i.e. on how to get it from the source up to what the
-target needs at runtime. This information is provided by a rule file per
+target needs at run-time. This information is provided by a rule file per
PTXdist collects all rule files in its ``rules/`` directory. Whenever
@@ -97,11 +97,11 @@ project.
-Many packages are using runtime configuration files along with their
+Many packages are using run-time configuration files along with their
executables and libraries. PTXdist provides default configuration files
for the most common cases. These files can be found in the
``generic/etc`` directory and they are using the same names as the ones
-at runtime (and their install directory on the target side will also be
+at run-time (and their install directory on the target side will also be
But some of these default configuration files are empty, due to the
@@ -176,7 +176,7 @@ handle:
- **file**: This kind of package is intended to add a few simple files
into the build process. We assume these files do not need any
processing, they are ready to use and must only be present in the
- build process or at runtime (HTML files for example). Refer to the
+ build process or at run-time (HTML files for example). Refer to the
section :ref:`adding_files` for further details on how to use
@@ -927,7 +927,7 @@ provides the features *foo* and *bar* and its ``configure`` provides
switches to enable/disable them independently, we can also add
dependencies on demand. Let’s assume feature *foo* needs the compression
library *libz* and *bar* needs the XML2 library *libxml2*. These
-libraries are only required at runtime if the correspondig feature is
+libraries are only required at run-time if the correspondig feature is
enabled. To add these dependencies on demand, the menu file looks like:
@@ -975,10 +975,10 @@ In our example there is a hidden dependency to the math library
``libm``. Our new package was built successfully, because the linker was
able to link our binaries against the ``libm`` from the toolchain. But
in this case the ``libm`` must also be available in the target’s root
-filesystem to fulfil the runtime dependency: We have to force PTXdist to
+filesystem to fulfil the run-time dependency: We have to force PTXdist to
install ``libm``. ``libm`` is part of the *glibc* package, but is not
installed by default (to keep the root filesystem small). So, it **does
-not** help to select the ``GLIBC`` symbol, to get a ``libm`` at runtime.
+not** help to select the ``GLIBC`` symbol, to get a ``libm`` at run-time.
The correct solution here is to add a ``select LIBC_M`` to our menu
file. With all the additions above it now looks like:
diff --git a/doc/environment.rst b/doc/environment.rst
index 3a4c96d64..e519bd493 100644
@@ -292,7 +292,7 @@ cross compiler instead of the native one:
$ arm-softfloat-linux-gnu-gcc test.c -o test
-Also part of what we consider to be the “toolchain” is the runtime
+Also part of what we consider to be the “toolchain” is the run-time
library (libc, dynamic linker). All programs running on the embedded
system are linked against the libc, which also offers the interface from
user space functions to the kernel.
@@ -305,7 +305,7 @@ floating point code, it will fail. This is also the case when the
toolchain builds code for i686 CPUs, whereas the target is i586.
So in order to make things working consistently it is necessary that the
-runtime libc is identical with the libc the compiler was built against.
+run-time libc is identical with the libc the compiler was built against.
PTXdist doesn’t contain a pre-built binary toolchain. Remember that it’s
not a distribution but a development tool. But it can be used to build a
diff --git a/doc/ref_manual.rst b/doc/ref_manual.rst
index 4201c945f..85cdfef9f 100644
@@ -55,7 +55,7 @@ Global Variables
packages built for the target are searching in this directory tree for
their dependencies (header and library files). These files are for
compile time only (for example to link a target executable against a
- target library), not for runtime! Use
+ target library), not for run-time! Use
``$(PTXDIST_SYSROOT_TARGET)/include`` for header files and
``$(PTXDIST_SYSROOT_TARGET)/lib`` for libraries.
@@ -845,7 +845,7 @@ The parameters and their meanings:
The ``install_lib`` macro searches for the library at the most
common directories ``/lib`` and ``/usr/lib``. And it searches always
in the package's corresponding directory in ``<platform-dir>/packages/``.
-It also handles all required links to make the library work at runtime.
+It also handles all required links to make the library work at run-time.
diff --git a/doc/user_manual.rst b/doc/user_manual.rst
index 0ec387ec7..ad1b11206 100644
@@ -36,7 +36,7 @@ required software components.
- Userland (root filesystem)
-- Adapted files (or generic ones) for runtime configuration
+- Adapted files (or generic ones) for run-time configuration
- Patches for all kind of components (to fix bugs or improve features)
@@ -291,8 +291,8 @@ Notes about some of the files and directories listed above:
- Contains files and configuration for the target’s runtime. A running
- GNU/Linux system uses many text files for runtime configuration.
+ Contains files and configuration for the target’s run-time. A running
+ GNU/Linux system uses many text files for run-time configuration.
Most of the time, the generic files from the PTXdist installation
will fit the needs. But if not, customized files are located in this