@c Permission is granted to copy, distribute and/or modify this document
@c under the terms of the GNU Free Documentation License, Version 1.3 or
@c Permission is granted to copy, distribute and/or modify this document
@c under the terms of the GNU Free Documentation License, Version 1.3 or
-It prevents abuse of undocumented APIs of your library. Symbols that
-are not exported from the library cannot be used. This eliminates the
+It prevents abuse of undocumented APIs of your library. Symbols that
+are not exported from the library cannot be used. This eliminates the
maintainers are forced to negotiate the desired API from the maintainer
of the library.
@item
It reduces the risk of symbol collision between your library and other
maintainers are forced to negotiate the desired API from the maintainer
of the library.
@item
It reduces the risk of symbol collision between your library and other
libraries, most of which don't have the same semantics and the same calling
convention as the GNU readline library.
@item
libraries, most of which don't have the same semantics and the same calling
convention as the GNU readline library.
@item
-It allows the compiler to generate better code. Within a shared library,
-a call to a function that is a global symbol costs a "call" instruction
+It allows the compiler to generate better code. Within a shared library,
+a call to a function that is a global symbol costs a ``call'' instruction
needed so that the function can be overridden, for example by a function
with the same name in the executable or in a shared library interposed
with @code{LD_PRELOAD}.) Whereas a call to a function for which the compiler
needed so that the function can be overridden, for example by a function
with the same name in the executable or in a shared library interposed
with @code{LD_PRELOAD}.) Whereas a call to a function for which the compiler
-can assume that it is in the same shared library is just a direct "call"
-instructions. Similarly for variables: A reference to a global variable
+can assume that it is in the same shared library is just a direct ``call''
+instructions. Similarly for variables: A reference to a global variable
-pointer to the variable's memory. So the code to access it is two memory
-load instructions. Whereas for a variable which is known to reside in the
+pointer to the variable's memory. So the code to access it is two memory
+load instructions. Whereas for a variable which is known to reside in the
to the linker, with the name of a file containing the symbols.
The upside of this approach is flexibility: it allows the same code to
to the linker, with the name of a file containing the symbols.
The upside of this approach is flexibility: it allows the same code to
are: 1. it's a lot of maintenance overhead when the symbol list is platform
dependent, 2. it doesn't work well with C++, due to name mangling.
@item
are: 1. it's a lot of maintenance overhead when the symbol list is platform
dependent, 2. it doesn't work well with C++, due to name mangling.
@item
function that shall not be exported.
The drawbacks of this approach are: Symbols are still exported from
function that shall not be exported.
The drawbacks of this approach are: Symbols are still exported from
-the library by default. It's a lot of maintenance work to mark every non-
-exported variable and function. But usually the exported API is quite small,
-compared to the internal API of the library. And it's the wrong paradigm:
+the library by default. It's a lot of maintenance work to mark every non-
+exported variable and function. But usually the exported API is quite small,
+compared to the internal API of the library. And it's the wrong paradigm:
-The programmer specifies a "hidden" attribute for all files that make up
-the shared library, and an "exported" attribute for those symbols in these
+The programmer specifies a ``hidden'' attribute for all files that make up
+the shared library, and an ``exported'' attribute for those symbols in these
files that shall be exported.
This is perfect: It burdens the maintainer only for exported API, not
files that shall be exported.
This is perfect: It burdens the maintainer only for exported API, not
was already supported in GCC 3.4, but without the command line option,
introduced in GCC 4.0, the third approach could not be used.)
was already supported in GCC 3.4, but without the command line option,
introduced in GCC 4.0, the third approach could not be used.)
The gnulib autoconf macro @code{gl_VISIBILITY} tests for GCC 4.0 or newer.
It defines a Makefile variable @code{@@CFLAG_VISIBILITY@@} containing
The gnulib autoconf macro @code{gl_VISIBILITY} tests for GCC 4.0 or newer.
It defines a Makefile variable @code{@@CFLAG_VISIBILITY@@} containing
-@samp{-fvisibility=hidden} or nothing. It also defines as a C macro and
-as a substituted variable: @@HAVE_VISIBILITY@@. Its value is 1 when symbol
+@samp{-fvisibility=hidden} or nothing. It also defines as a C macro and
+as a substituted variable: @@HAVE_VISIBILITY@@. Its value is 1 when symbol
visibility control is supported, and 0 otherwise.
To use this module in a library, say libfoo, you will do these steps:
visibility control is supported, and 0 otherwise.
To use this module in a library, say libfoo, you will do these steps:
can occur at different locations: between the @samp{extern} and the
type or return type, or just before the entity being declared, or after
can occur at different locations: between the @samp{extern} and the
type or return type, or just before the entity being declared, or after
so that the declarations in the header files remain halfway readable.
@end enumerate
Note that the precise control of the exported symbols will not work with
other compilers than GCC >= 4.0, and will not work on systems where the
so that the declarations in the header files remain halfway readable.
@end enumerate
Note that the precise control of the exported symbols will not work with
other compilers than GCC >= 4.0, and will not work on systems where the
it's good if, in order to reduce the risk of collisions with symbols in
other libraries, you continue to use a prefix specific to your library
for all non-static variables and functions and for all C++ classes in
it's good if, in order to reduce the risk of collisions with symbols in
other libraries, you continue to use a prefix specific to your library
for all non-static variables and functions and for all C++ classes in