mirror of https://github.com/mkerrisk/man-pages
iconv.1, locale.1, localedef.1, memusage.1, memusagestat.1, mtrace.1, pldd.1, sprof.1, time.1, iconvconfig.8, ld.so.8, ldconfig.8, sln.8: Formatting fix: replace blank lines with .PP/.IP
Blank lines shouldn't generally appear in *roff source (other than in code examples), since they create large vertical spaces between text blocks. Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk
parent
224a0025ee
commit
2a86152e72
|
|
@ -64,14 +64,14 @@ for input characters.
|
|||
Use
|
||||
.I to-encoding
|
||||
for output characters.
|
||||
|
||||
.IP
|
||||
If the string
|
||||
.BR //IGNORE
|
||||
is appended to
|
||||
.IR to-encoding ,
|
||||
characters that cannot be converted are discarded and an error is
|
||||
printed after conversion.
|
||||
|
||||
.IP
|
||||
If the string
|
||||
.BR //TRANSLIT
|
||||
is appended to
|
||||
|
|
@ -180,7 +180,7 @@ Usual system gconv module configuration cache.
|
|||
POSIX.1-2001.
|
||||
.SH EXAMPLE
|
||||
Convert text from the ISO 8859-15 character encoding to UTF-8:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBiconv \-f ISO\-8859\-15 \-t UTF\-8 < input.txt > output.txt\fP
|
||||
|
|
@ -189,7 +189,7 @@ $ \fBiconv \-f ISO\-8859\-15 \-t UTF\-8 < input.txt > output.txt\fP
|
|||
.PP
|
||||
The next example converts from UTF-8 to ASCII, transliterating when
|
||||
possible:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBecho abc ß α € àḃç | iconv \-f UTF\-8 \-t ASCII//TRANSLIT\fP
|
||||
|
|
|
|||
|
|
@ -37,7 +37,7 @@ The
|
|||
.B locale
|
||||
command displays information about the current locale, or all locales,
|
||||
on standard output.
|
||||
|
||||
.PP
|
||||
When invoked without arguments,
|
||||
.B locale
|
||||
displays the current locale settings for each locale category (see
|
||||
|
|
@ -47,7 +47,7 @@ based on the settings of the environment variables that control the locale
|
|||
.BR locale (7)).
|
||||
Values for variables set in the environment are printed without double
|
||||
quotes, implied values are printed with double quotes.
|
||||
|
||||
.PP
|
||||
If either the
|
||||
.B \-a
|
||||
or the
|
||||
|
|
@ -94,11 +94,11 @@ When arguments are supplied, the following options are meaningful:
|
|||
For a category name argument,
|
||||
write the name of the locale category
|
||||
on a separate line preceding the list of keyword values for that category.
|
||||
|
||||
.IP
|
||||
For a keyword name argument,
|
||||
write the name of the locale category for this keyword
|
||||
on a separate line preceding the keyword value.
|
||||
|
||||
.IP
|
||||
This option improves readability when multiple name arguments are specified.
|
||||
It can be combined with the
|
||||
.B \-k
|
||||
|
|
@ -108,7 +108,7 @@ option.
|
|||
For each keyword whose value is being displayed,
|
||||
include also the name of that keyword,
|
||||
so that the output has the format:
|
||||
|
||||
.IP
|
||||
\fIkeyword\fP="\fIvalue\fP"
|
||||
.PP
|
||||
The
|
||||
|
|
@ -178,7 +178,7 @@ int_select="11"
|
|||
int_prefix="1"
|
||||
telephone\-codeset="UTF\-8"
|
||||
.fi
|
||||
|
||||
.PP
|
||||
The following example compiles a custom locale from the
|
||||
.I ./wrk
|
||||
directory with the
|
||||
|
|
@ -193,7 +193,7 @@ and
|
|||
.B LANG
|
||||
in the shell profile file so that the custom locale will be used in the
|
||||
subsequent user sessions:
|
||||
|
||||
.PP
|
||||
.nf
|
||||
$ \fBmkdir -p $HOME/.locale\fP
|
||||
$ \fBI18NPATH=./wrk/ localedef -f UTF-8 -i fi_SE $HOME/.locale/fi_SE.UTF-8\fP
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ locale functions in the C library
|
|||
.BR localeconv (3),
|
||||
etc.), and places the output in
|
||||
.IR outputpath .
|
||||
|
||||
.PP
|
||||
The
|
||||
.I outputpath
|
||||
argument is interpreted as follows:
|
||||
|
|
|
|||
|
|
@ -119,7 +119,7 @@ For
|
|||
.BR realloc (3),
|
||||
the additional field "free" shows reallocations that
|
||||
caused a block to be freed (i.e., the reallocated size was 0).
|
||||
|
||||
.PP
|
||||
The "realloc/total memory" of the table output by
|
||||
.B memusage
|
||||
does not reflect cases where
|
||||
|
|
@ -208,7 +208,7 @@ reallocating the memory in smaller blocks that return to zero.
|
|||
After compiling the program and running the following commands,
|
||||
a graph of the memory usage of the program can be found in the file
|
||||
.IR memusage.png :
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBmemusage --data=memusage.dat ./a.out\fP
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ that file is generated via the
|
|||
.IR --data )
|
||||
option of
|
||||
.BR memusage (1).
|
||||
|
||||
.PP
|
||||
The red line in the graph shows the heap usage (allocated memory)
|
||||
and the green line shows the stack usage.
|
||||
The x-scale is either the number of memory-handling function calls or
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ for problem locations
|
|||
(assuming that
|
||||
.I binary
|
||||
was compiled with debugging information).
|
||||
|
||||
.PP
|
||||
For more information about the
|
||||
.BR mtrace (3)
|
||||
function and
|
||||
|
|
|
|||
|
|
@ -79,7 +79,7 @@ lsof \-p PID
|
|||
.PP
|
||||
also shows output that includes the dynamic shared objects
|
||||
that are linked into a process.
|
||||
|
||||
.PP
|
||||
The
|
||||
.BR gdb (1)
|
||||
.I "info shared"
|
||||
|
|
|
|||
24
man1/sprof.1
24
man1/sprof.1
|
|
@ -82,7 +82,7 @@ The following example demonstrates the use of
|
|||
The example consists of a main program that calls two functions
|
||||
in a shared object.
|
||||
First, the code of the main program:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBcat prog.c\fP
|
||||
|
|
@ -107,7 +107,7 @@ and
|
|||
.IR x2()
|
||||
are defined in the following source file that is used to
|
||||
construct the shared object:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBcat libdemo.c\fP
|
||||
|
|
@ -154,7 +154,7 @@ Now we construct the shared object with the real name
|
|||
.IR libdemo.so.1.0.1 ,
|
||||
and the soname
|
||||
.IR libdemo.so.1 :
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBcc \-g \-fPIC \-shared \-Wl,\-soname,libdemo.so.1 \e\fP
|
||||
|
|
@ -164,7 +164,7 @@ $ \fBcc \-g \-fPIC \-shared \-Wl,\-soname,libdemo.so.1 \e\fP
|
|||
.PP
|
||||
Then we construct symbolic links for the library soname and
|
||||
the library linker name:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBln \-sf libdemo.so.1.0.1 libdemo.so.1\fP
|
||||
|
|
@ -174,7 +174,7 @@ $ \fBln \-sf libdemo.so.1 libdemo.so\fP
|
|||
.PP
|
||||
Next, we compile the main program, linking it against the shared object,
|
||||
and then list the dynamic dependencies of the program:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBcc \-g \-o prog prog.c \-L. \-ldemo\fP
|
||||
|
|
@ -190,7 +190,7 @@ In order to get profiling information for the shared object,
|
|||
we define the environment variable
|
||||
.BR LD_PROFILE
|
||||
with the soname of the library:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBexport LD_PROFILE=libdemo.so.1\fP
|
||||
|
|
@ -201,7 +201,7 @@ We then define the environment variable
|
|||
.BR LD_PROFILE_OUTPUT
|
||||
with the pathname of the directory where profile output should be written,
|
||||
and create that directory if it does not exist already:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBexport LD_PROFILE_OUTPUT=$(pwd)/prof_data\fP
|
||||
|
|
@ -214,7 +214,7 @@ causes profiling output to be
|
|||
.I appended
|
||||
to the output file if it already exists,
|
||||
so we ensure that there is no preexisting profiling data:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBrm \-f $LD_PROFILE_OUTPUT/$LD_PROFILE.profile\fP
|
||||
|
|
@ -224,7 +224,7 @@ $ \fBrm \-f $LD_PROFILE_OUTPUT/$LD_PROFILE.profile\fP
|
|||
We then run the program to produce the profiling output,
|
||||
which is written to a file in the directory specified in
|
||||
.BR LD_PROFILE_OUTPUT :
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBLD_LIBRARY_PATH=. ./prog\fP
|
||||
|
|
@ -236,7 +236,7 @@ libdemo.so.1.profile
|
|||
We then use the
|
||||
.BR "sprof \-p"
|
||||
option to generate a flat profile with counts and ticks:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBsprof \-p libdemo.so.1 $LD_PROFILE_OUTPUT/libdemo.so.1.profile\fP
|
||||
|
|
@ -255,7 +255,7 @@ Each sample counts as 0.01 seconds.
|
|||
The
|
||||
.BR "sprof \-q"
|
||||
option generates a call graph:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBsprof \-q libdemo.so.1 $LD_PROFILE_OUTPUT/libdemo.so.1.profile\fP
|
||||
|
|
@ -286,7 +286,7 @@ are outside of the profiled object (in this example, these are instances of
|
|||
The
|
||||
.BR "sprof \-c"
|
||||
option generates a list of call pairs and the number of their occurrences:
|
||||
|
||||
.PP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBsprof \-c libdemo.so.1 $LD_PROFILE_OUTPUT/libdemo.so.1.profile\fP
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ values in a
|
|||
.I "struct tms"
|
||||
as returned by
|
||||
.BR times (2)).
|
||||
|
||||
.PP
|
||||
Note: some shells (e.g.,
|
||||
.BR bash (1))
|
||||
have a built-in
|
||||
|
|
|
|||
|
|
@ -42,12 +42,12 @@ Loading and parsing such a configuration file would slow down
|
|||
programs that use
|
||||
.BR iconv (3),
|
||||
so a caching mechanism is employed.
|
||||
|
||||
.PP
|
||||
The
|
||||
.B iconvconfig
|
||||
program reads iconv module configuration files and writes
|
||||
a fast-loading gconv module configuration cache file.
|
||||
|
||||
.PP
|
||||
In addition to the system provided gconv modules, the user can specify
|
||||
custom gconv module directories with the environment variable
|
||||
.BR GCONV_PATH .
|
||||
|
|
|
|||
42
man8/ld.so.8
42
man8/ld.so.8
|
|
@ -110,9 +110,9 @@ the directory containing the program or shared object.
|
|||
Thus, an application located in
|
||||
.I somedir/app
|
||||
could be compiled with
|
||||
|
||||
.IP
|
||||
gcc \-Wl,\-rpath,\(aq$ORIGIN/../lib\(aq
|
||||
|
||||
.IP
|
||||
so that it finds an associated shared object in
|
||||
.I somedir/lib
|
||||
no matter where
|
||||
|
|
@ -229,7 +229,7 @@ At run time,
|
|||
the dynamic linker determines the ABI version of the running kernel and
|
||||
will reject loading shared objects that specify minimum ABI versions
|
||||
that exceed that ABI version.
|
||||
|
||||
.IP
|
||||
.BR LD_ASSUME_KERNEL
|
||||
can be used to
|
||||
cause the dynamic linker to assume that it is running on a system with
|
||||
|
|
@ -238,20 +238,20 @@ For example, the following command line causes the
|
|||
dynamic linker to assume it is running on Linux 2.2.5 when loading
|
||||
the shared objects required by
|
||||
.IR myprog :
|
||||
|
||||
.IP
|
||||
.in +4n
|
||||
.nf
|
||||
$ \fBLD_ASSUME_KERNEL=2.2.5 ./myprog\fP
|
||||
.fi
|
||||
.in
|
||||
|
||||
.IP
|
||||
On systems that provide multiple versions of a shared object
|
||||
(in different directories in the search path) that have
|
||||
different minimum kernel ABI version requirements,
|
||||
.BR LD_ASSUME_KERNEL
|
||||
can be used to select the version of the object that is used
|
||||
(dependent on the directory search order).
|
||||
|
||||
.IP
|
||||
Historically, the most common use of the
|
||||
.BR LD_ASSUME_KERNEL
|
||||
feature was to manually select the older
|
||||
|
|
@ -275,9 +275,9 @@ The items in the list are separated by either colons or semicolons.
|
|||
Similar to the
|
||||
.B PATH
|
||||
environment variable.
|
||||
|
||||
.IP
|
||||
This variable is ignored in secure-execution mode.
|
||||
|
||||
.IP
|
||||
Within the pathnames specified in
|
||||
.BR LD_LIBRARY_PATH ,
|
||||
the dynamic linker expands the tokens
|
||||
|
|
@ -313,13 +313,13 @@ objects to be loaded before all others.
|
|||
The items of the list can be separated by spaces or colons.
|
||||
This can be used to selectively override functions in other shared objects.
|
||||
The objects are searched for using the rules given under DESCRIPTION.
|
||||
|
||||
.IP
|
||||
In secure-execution mode,
|
||||
preload pathnames containing slashes are ignored.
|
||||
Furthermore, shared objects are preloaded only
|
||||
from the standard search directories and only
|
||||
if they have set-user-ID mode bit enabled (which is not typical).
|
||||
|
||||
.IP
|
||||
Within the names specified in the
|
||||
.BR LD_PRELOAD
|
||||
list, the dynamic linker understands the tokens
|
||||
|
|
@ -465,14 +465,14 @@ If
|
|||
.B LD_DEBUG_OUTPUT
|
||||
is defined, then output is written to the pathname specified by its value,
|
||||
with the suffix "." (dot) followed by the process ID appended to the pathname.
|
||||
|
||||
.IP
|
||||
.B LD_DEBUG_OUTPUT
|
||||
is ignored in secure-execution mode.
|
||||
.TP
|
||||
.BR LD_DYNAMIC_WEAK " (since glibc 2.1.91)"
|
||||
By default, when searching shared libraries to resolve a symbol reference,
|
||||
the dynamic linker will resolve to the first definition it finds.
|
||||
|
||||
.IP
|
||||
Old glibc versions (before 2.2), provided a different behavior:
|
||||
if the linker found a symbol that was weak,
|
||||
it would remember that symbol and
|
||||
|
|
@ -481,7 +481,7 @@ If it subsequently found a strong definition of the same symbol,
|
|||
then it would instead use that definition.
|
||||
(If no further symbol was found,
|
||||
then the dynamic linker would use the weak symbol that it initially found.)
|
||||
|
||||
.IP
|
||||
The old glibc behavior was nonstandard.
|
||||
(Standard practice is that the distinction between
|
||||
weak and strong symbols should have effect only at static link time.)
|
||||
|
|
@ -497,7 +497,7 @@ In glibc 2.2,
|
|||
the dynamic linker was modified to provide the current behavior
|
||||
(which was the behavior that was provided by most other implementations
|
||||
at that time).
|
||||
|
||||
.IP
|
||||
Defining the
|
||||
.B LD_DYNAMIC_WEAK
|
||||
environment variable (with any value) provides
|
||||
|
|
@ -507,7 +507,7 @@ a strong symbol subsequently discovered in another shared library.
|
|||
(Note that even when this variable is set,
|
||||
a strong symbol in a shared library will not override
|
||||
a weak definition of the same symbol in the main program.)
|
||||
|
||||
.IP
|
||||
Since glibc 2.3.4,
|
||||
.B LD_DYNAMIC_WEAK
|
||||
is ignored in secure-execution mode.
|
||||
|
|
@ -519,7 +519,7 @@ Mask for hardware capabilities.
|
|||
Path where the binary is found.
|
||||
.\" Used only if $ORIGIN can't be determined by normal means
|
||||
.\" (from the origin path saved at load time, or from /proc/self/exe)?
|
||||
|
||||
.IP
|
||||
Since glibc 2.4,
|
||||
.B LD_ORIGIN_PATH
|
||||
is ignored in secure-execution mode.
|
||||
|
|
@ -545,7 +545,7 @@ The name of a (single) shared object to be profiled,
|
|||
specified either as a pathname or a soname.
|
||||
Profiling output is appended to the file whose name is:
|
||||
"\fI$LD_PROFILE_OUTPUT\fP/\fI$LD_PROFILE\fP.profile".
|
||||
|
||||
.IP
|
||||
Since glibc 2.2.5,
|
||||
.BR LD_PROFILE
|
||||
is ignored in secure-execution mode.
|
||||
|
|
@ -557,7 +557,7 @@ output should be written.
|
|||
If this variable is not defined, or is defined as an empty string,
|
||||
then the default is
|
||||
.IR /var/tmp .
|
||||
|
||||
.IP
|
||||
.B LD_PROFILE_OUTPUT
|
||||
is ignored in secure-execution mode; instead
|
||||
.IR /var/profile
|
||||
|
|
@ -571,7 +571,7 @@ is also ignored in secure-execution mode.)
|
|||
If this environment variable is defined (with any value),
|
||||
show the auxiliary array passed up from the kernel (see also
|
||||
.BR getauxval (3)).
|
||||
|
||||
.IP
|
||||
Since glibc 2.3.4,
|
||||
.B LD_SHOW_AUXV
|
||||
is ignored in secure-execution mode.
|
||||
|
|
@ -604,7 +604,7 @@ If
|
|||
.B LD_USE_LOAD_BIAS
|
||||
is defined with the value 0,
|
||||
neither executables nor PIEs will honor the base addresses.
|
||||
|
||||
.IP
|
||||
Since glibc 2.3.3, this variable is ignored in secure-execution mode.
|
||||
.TP
|
||||
.BR LD_VERBOSE " (since glibc 2.1)"
|
||||
|
|
@ -628,7 +628,7 @@ will first try to map executable pages using the
|
|||
.BR MAP_32BIT
|
||||
flag, and fall back to mapping without that flag if that attempt fails.
|
||||
NB: MAP_32BIT will map to the low 2GB (not 4GB) of the address space.
|
||||
|
||||
.IP
|
||||
Because
|
||||
.B MAP_32BIT
|
||||
reduces the address range available for address space layout
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ are the trusted directories for 32-bit libraries, while
|
|||
and
|
||||
.IR /usr/lib64
|
||||
are used for 64-bit libraries).
|
||||
|
||||
.PP
|
||||
The cache is used by the run-time linker,
|
||||
.I ld.so
|
||||
or
|
||||
|
|
|
|||
|
|
@ -39,13 +39,13 @@ program, it is statically linked.
|
|||
This means that if for some reason the dynamic linker is not working,
|
||||
.BR sln
|
||||
can be used to make symbolic links to dynamic libraries.
|
||||
|
||||
.PP
|
||||
The command line has two forms.
|
||||
In the first form, it creates
|
||||
.I dest
|
||||
as a new symbolic link to
|
||||
.IR source .
|
||||
|
||||
.PP
|
||||
In the second form,
|
||||
.I filelist
|
||||
is a list of space-separated pathname pairs,
|
||||
|
|
@ -53,7 +53,7 @@ and the effect is as if
|
|||
.BR sln
|
||||
was executed once for each line of the file,
|
||||
with the two pathnames as the arguments.
|
||||
|
||||
.PP
|
||||
The
|
||||
.B sln
|
||||
program supports no command-line options.
|
||||
|
|
|
|||
Loading…
Reference in New Issue