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
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
.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
.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
.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
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
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
int_prefix="1"
telephone\-codeset="UTF\-8"
.fi
-
+.PP
The following example compiles a custom locale from the
.I ./wrk
directory with the
.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
.BR localeconv (3),
etc.), and places the output in
.IR outputpath .
-
+.PP
The
.I outputpath
argument is interpreted as follows:
.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
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
.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
(assuming that
.I binary
was compiled with debugging information).
-
+.PP
For more information about the
.BR mtrace (3)
function and
.PP
also shows output that includes the dynamic shared objects
that are linked into a process.
-
+.PP
The
.BR gdb (1)
.I "info shared"
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
.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
.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
.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
.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
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
.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
.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
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
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
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
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
.I "struct tms"
as returned by
.BR times (2)).
-
+.PP
Note: some shells (e.g.,
.BR bash (1))
have a built-in
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 .
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
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
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
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
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
.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
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.)
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
(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.
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.
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.
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
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.
.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)"
.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
and
.IR /usr/lib64
are used for 64-bit libraries).
-
+.PP
The cache is used by the run-time linker,
.I ld.so
or
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,
.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.
projects / thirdparty / man-pages.git / commitdiff
