Source strings

13 Strings 100%
Browse Translate
742 Words 100%
5,094 Characters 100%
This translation is being used as source strings within this component.

Strings status

Strings Words Characters
13 742 5,094
All strings Browse Translate Zen
13 742 5,094
Read-only strings Browse Translate Zen
1 46 408
Strings with any failing checks Browse Translate Zen
1 46 408
Failing check: Unpluralised Browse Translate Zen

Overview

Project website www.linuxfromscratch.org
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository git@git.linuxfromscratch.org:fr-lfs
Repository branch trunk
Last remote commit Automatic BLFS commit based on ea511400c9ad6f1baca13debd05f2b10ac984059 e362137d3e
Julien Lepiller authored 4 hours ago
Last commit in Weblate Automatic BLFS commit based on ea511400c9ad6f1baca13debd05f2b10ac984059 e362137d3e
Julien Lepiller authored 4 hours ago
Weblate repository https://translate.linuxfromscratch.org/git/faq/faq/
File mask blfs/*/introduction/important/libraries.po
Translation file Not available
Last change March 5, 2023, 11:47 a.m.
Last author None
2 weeks ago

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 13 742 5,094
Translated 100% 13 100% 742 100% 5,094
Needs editing 0% 0 0% 0 0% 0
Read-only 100% 13 100% 742 100% 5,094
Failing checks 7% 1 6% 46 8% 408
Strings with suggestions 0% 0 0% 0 0% 0
Untranslated strings 0% 0 0% 0 0% 0
Last 12 months Previous

Activity in last 12 months

0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 14 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes 0 changes
Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct

Quick numbers

742
Hosted words
13
Hosted strings
100%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+100%
—
Contributors
—
User avatar None

Source string added
Sometimes, deciding to use system libraries is an easy decision. Other times it may require you to alter the system version (e.g. for <xref linkend="libpng"/> if used for <xref linkend="firefox"/>). Occasionally, a package ships an old library and can no longer link to the current version, but can link to an older version. In this case, BLFS will usually just use the shipped version. Sometimes the included library is no longer developed separately, or its upstream is now the same as the package&apos;s upstream and you have no other packages which will use it. In those cases, you'll be lead to use the included library even if you usually prefer to use system libraries.
a year ago
User avatar None

Source string added
When BLFS mentions system libraries, it means shared versions of libraries. Some packages such as <xref linkend="firefox"/> and <xref linkend="gs"/> bundle many other libraries in their build tree. The version they ship is often older than the version used in the system, so it may contain bugs &ndash; sometimes developers go to the trouble of fixing bugs in their included libraries, other times they do not.
a year ago
User avatar None

Source string added
Many packages put some of their common functions into a static library which is only used by the programs within the package and, crucially, the library is <emphasis>not</emphasis> installed as a standalone library. These internal libraries are not a problem &ndash; if the package has to be rebuilt to fix a bug or vulnerability, nothing else is linked to them.
a year ago
User avatar None

Source string added
If you use this approach, you may discover that more packages than you were expecting use a static library. That was the case with <application>nettle-2.4</application> in its default static-only configuration: It was required by <application>GnuTLS-3.0.19</application>, but also linked into package(s) which used <application>GnuTLS</application>, such as <application>glib-networking-2.32.3</application>.
a year ago
User avatar None

Source string added
One way to identify when a static library is used, is to deal with it at the end of the installation of every package. Write a script to find all the static libraries in <filename class="directory">/usr/lib</filename> or wherever you are installing to, and either move them to another directory so that they are no longer found by the linker, or rename them so that <filename>libfoo.a</filename> becomes e.g. <filename>libfoo.a.hidden</filename>. The static library can then be temporarily restored if it is ever needed, and the package needing it can be identified. This shouldn't be done blindly since many libraries only exist in a static version. For example, some libraries from the <application>glibc</application> and <application>gcc</application> packages should always be present on the system (<filename>libc_nonshared.a, libg.a, libpthread_nonshared.a, libssp_nonshared.a, libsupc++.a</filename> as of glibc-2.36 and gcc-12.2).
a year ago
User avatar None

Source string added
If a package is linked to a dynamic library, updating to a newer library version is automatic once the newer library is installed and the program is (re)started (provided the library major version is unchanged, e.g. going from <filename>libfoo.so.2.0</filename> to <filename>libfoo.so.2.1</filename>. Going to <filename>libfoo.so.3</filename> will require recompilation &ndash; <command>ldd</command> can be used to find which programs use the old version). If a program is linked to a static library, the program always has to be recompiled. If you know which programs are linked to a particular static library, this is merely an annoyance. But usually you will <emphasis>not</emphasis> know which programs to recompile.
a year ago
User avatar None

Source string added
Within the book, there are various places where configure switches such as <parameter>--disable-static</parameter> are employed, and other places where the possibility of using system versions of libraries instead of the versions included within another package is discussed. The main reason for this is to simplify updates of libraries.
a year ago
User avatar None

Source string added
In the past, essential programs such as a shell were often linked statically so that some form of minimal recovery system would exist even if shared libraries, such as <filename>libc.so</filename>, became damaged (e.g. moved to <filename class="directory">lost+found</filename> after <command>fsck</command> following an unclean shutdown). Nowadays, most people use an alternative system install or a USB stick if they have to recover. Journaling filesystems also reduce the likelihood of this sort of problem.
a year ago
User avatar None

Source string added
On almost all Linux platforms there are also <quote>shared</quote> (or equivalently <quote>dynamic</quote>) libraries (with names of the form <filename>libfoo.so</filename>) &ndash; one copy of the library is loaded into virtual memory, and shared by all the programs which call any of its functions. This is space efficient.
a year ago
User avatar None

Source string added
The original libraries were simply an archive of routines from which the required routines were extracted and linked into the executable program. These are described as static libraries, with names of the form <filename>libfoo.a</filename> on UNIX-like operating systems. On some old operating systems they are the only type available.
a year ago
Browse all translation changes