Provided by: dpkg-dev_1.18.4ubuntu1.7_all 
NOMBRE
dpkg-gensymbols - Generación de ficheros «symbols» (información de dependencia de
bibliotecas compartidas)
SINOPSIS
dpkg-gensymbols [opción...]
DESCRIPCIÓN
dpkg-gensymbols analiza un árbol temporal de construcción («debian/tmp» por omisión) en
busca de bibliotecas para generar un fichero symbols que los describa. Este fichero, si no
está vacío, se instala en el subdirectorio «DEBIAN» del árbol de construcción, para
después incluir el contenido en la información de control del paquete.
Al generar estos ficheros, usa algunos ficheros «symbols» como entrada proporcionados por
el desarrollador. Busca los siguientes ficheros, utilizando el primero que encuentra.
• debian/package.symbols.arch
• debian/symbols.arch
• debian/package.symbols
• debian/symbols
The main interest of those files is to provide the minimal version associated to each
symbol provided by the libraries. Usually it corresponds to the first version of that
package that provided the symbol, but it can be manually incremented by the maintainer if
the ABI of the symbol is extended without breaking backwards compatibility. It's the
responsibility of the maintainer to keep those files up-to-date and accurate, but
dpkg-gensymbols helps with that.
Cuando los ficheros «symbols» generados difieren del proporcionado por el desarrollador,
dpkg-gensymbols mostrará las diferencias entre ambas versiones. Más aún, puede que falle
si la diferencia es demasiado grande, (puede configurar cuanta diferencia tolerar,
consulte la opción -c).
MANTENER FICHEROS «SYMBOLS»
The symbols files are really useful only if they reflect the evolution of the package
through several releases. Thus the maintainer has to update them every time that a new
symbol is added so that its associated minimal version matches reality. The diffs
contained in the build logs can be used as a starting point, but the maintainer,
additionally, has to make sure that the behaviour of those symbols has not changed in a
way that would make anything using those symbols and linking against the new version, stop
working with the old version. In most cases, the diff applies directly to the
debian/package.symbols file. That said, further tweaks are usually needed: it's
recommended for example to drop the Debian revision from the minimal version so that
backports with a lower version number but the same upstream version still satisfy the
generated dependencies. If the Debian revision can't be dropped because the symbol really
got added by the Debian specific change, then one should suffix the version with ‘~’.
Antes de aplicar un parche al fichero «symbols» el desarrollador debería revisar
nuevamente que es adecuado. Se espera que los símbolos públicos no desaparezcan así que,
idealmente, el parche sólo debería añadir líneas nuevas.
Note that you can put comments in symbols files: any line with ‘#’ as the first character
is a comment except if it starts with ‘#include’ (see section Using includes). Lines
starting with ‘#MISSING:’ are special comments documenting symbols that have disappeared.
Do not forget to check if old symbol versions need to be increased. There is no way
dpkg-gensymbols can warn about this. Blindly applying the diff or assuming there is
nothing to change if there is no diff, without checking for such changes, can lead to
packages with loose dependencies that claim they can work with older packages they cannot
work with. This will introduce hard to find bugs with (partial) upgrades.
Usar la sustitución de #PACKAGE#
En algunos casos aislados el nombre de la biblioteca varía según la arquitectura. Puede
utilizar el marcador #PACKAGE# para evitar incrustar («hardcode») el nombre del paquete en
el fichero «symbols». Se reemplazará por el nombre real del paquete durante la instalación
de los ficheros «symbols». A diferencia del marcador #MINVER#, #PACKAGE# nunca aparecerá
en un fichero «symbols» contenido en un paquete binario.
Usar etiquetas de símbolos
Symbol tagging is useful for marking symbols that are special in some way. Any symbol can
have an arbitrary number of tags associated with it. While all tags are parsed and stored,
only some of them are understood by dpkg-gensymbols and trigger special handling of the
symbols. See subsection Standard symbol tags for reference of these tags.
La especificación de la etiqueta aparece a continuación del nombre del símbolo (no se
permite un espacio vacío entre estos). Siempre comienza con un paréntesis de apertura (,
finaliza con un paréntesis de cierre ), y debe contener al menos una etiqueta. Varias
etiquetas se separan con un carácter |. Opcionalmente, cada etiqueta puede tener un valor
separado del nombre de la etiqueta mediante el carácter =. Los nombres de etiqueta y
valores pueden ser cadenas arbitrarias, a excepción de que no pueden contener ningún
carácter especial: ), | y =. Los nombres de símbolo a continuación de una especificación
de etiqueta se pueden entrecomillar con caracteres ' o ", permitiendo así espacios vacíos.
Por otra parte, de no existir ninguna etiqueta definida para el símbolo, las comillas se
tratarán como parte del nombre del símbolo, continuando hasta el primer espacio.
(tag1=tengo una marca|nombre de etiqueta con espacio)"símbolo
entrecomillado y etiquetado"@Base 1.0
(optional)símbolo_sin_comillas_y_etiquetado@Base 1.0 1
símbolo_sin_etiquetar@Base 1.0
El primer símbolo del ejemplo se llama símbolo entrecomillado y etiquetado, y tiene dos
etiquetas: tag1, con el valor tengo una marca y nombre de etiqueta con espacio, que no
tiene valor. El segundo símbolo se llama símbolo_sin_comillas_y_etiquetado, y sólo tiene
una etiqueta llamada optional. El último símbolo es un ejemplo de un símbolo normal sin
etiquetar.
Since symbol tags are an extension of the deb-symbols(5) format, they can only be part of
the symbols files used in source packages (those files should then be seen as templates
used to build the symbols files that are embedded in binary packages). When
dpkg-gensymbols is called without the -t option, it will output symbols files compatible
to the deb-symbols(5) format: it fully processes symbols according to the requirements of
their standard tags and strips all tags from the output. On the contrary, in template mode
(-t) all symbols and their tags (both standard and unknown ones) are kept in the output
and are written in their original form as they were loaded.
Etiquetas de símbolo estándar
optional
A symbol marked as optional can disappear from the library at any time and that
will never cause dpkg-gensymbols to fail. However, disappeared optional symbols
will continuously appear as MISSING in the diff in each new package revision. This
behaviour serves as a reminder for the maintainer that such a symbol needs to be
removed from the symbol file or readded to the library. When the optional symbol,
which was previously declared as MISSING, suddenly reappears in the next revision,
it will be upgraded back to the “existing” status with its minimum version
unchanged.
Esta etiqueta es útil para aquellos símbolos privados cuya desaparición no rompe la
ABI. Por ejemplo, la mayoría de plantillas de producción de un objeto definido más
específicamente por medio del reemplazo de ciertas variables por valores
(«instantiation») de C++ se encuentran dentro de esta categoría. Al igual que con
cualquier otra etiqueta, éste puede tener un valor arbitrario: se puede utilizar
para indicar porqué el símbolo se considera opcional.
arch=architecture-list
arch-bits=architecture-bits
arch-endian=architecture-endianness
These tags allow one to restrict the set of architectures where the symbol is
supposed to exist. The arch-bits and arch-endian tags are supported since dpkg
1.18.0. When the symbols list is updated with the symbols discovered in the
library, all arch-specific symbols which do not concern the current host
architecture are treated as if they did not exist. If an arch-specific symbol
matching the current host architecture does not exist in the library, normal
procedures for missing symbols apply and it may cause dpkg-gensymbols to fail. On
the other hand, if the arch-specific symbol is found when it was not supposed to
exist (because the current host architecture is not listed in the tag or does not
match the endianness and bits), it is made arch neutral (i.e. the arch, arch-bits
and arch-endian tags are dropped and the symbol will appear in the diff due to this
change), but it is not considered as new.
Al operar en el modo por omisión (sin plantilla) sólo se escribirán al fichero
«symbols» aquellos símbolos específicos a la arquitectura que coinciden con la
arquitectura anfitrión. Por otra parte, en el modo plantilla todos los símbolos
específicos a la arquitectura (incluyendo arquitecturas alternativas) siempre se
escribirán al fichero «symbols».
The format of architecture-list is the same as the one used in the Build-Depends
field of debian/control (except the enclosing square brackets []). For example, the
first symbol from the list below will be considered only on alpha, any-amd64 and
ia64 architectures, the second only on linux architectures, while the third one
anywhere except on armel.
(arch=alpha any-amd64 ia64)a_64bit_símbolo_específico@Base 1.0
(arch=linux-any)símbolo_específico_linux@Base 1.0
(arch=!armel)símbolo_ausente_en_armel@Base 1.0
The architecture-bits is either 32 or 64.
(arch-bits=32)a_32bit_specific_symbol@Base 1.0
(arch-bits=64)a_64bit_specific_symbol@Base 1.0
The architecture-endianness is either little or big.
(arch-endian=little)a_little_endian_specific_symbol@Base 1.0
(arch-endian=big)a_big_endian_specific_symbol@Base 1.0
Multiple restrictions can be chained.
(arch-bits=32|arch-endian=little)a_32bit_le_symbol@Base 1.0
ignore-blacklist
dpkg-gensymbols tiene una lista negra interna de símbolos que no deberían aparecer
en los ficheros «symbols», ya que habitualmente son sólo efectos secundarios de los
detallas de implementación de la cadena de herramientas. Si por alguna razón desea
incluir uno de esos símbolos en el fichero «symbols» debería etiquetar el símbolo
con ignore-blacklist. Puede ser necesario con alguna cadena de herramientas de bajo
nivel como libgcc.
c++ Denota el patrón c++- Consulte la subsección a continuación Usar patrones de
símbolos.
symver Denota el patrón de símbolos symver (versión del símbolo). Consulte la sub-sección
a continuación Usar patrones de símbolos.
regex Denota el patrón de símbolos regex (expresión regular). Consulte la sub-sección a
continuación Usar patrones de símbolos.
Usar patrones de símbolos
A diferencia de cualquier definición de símbolo estándar un patrón puede cubrir varios
símbolos reales de la biblioteca. dpkg-gensymbols intentará emparejar cada patrón con cada
símbolo real que no tiene un símbolo específico de contrapartida definido en el fichero de
símbolos. En el momento que se encuentre el primer patrón que coincida se usarán todas sus
etiquetas y propiedades como un definición básica del símbolo. Si ninguno de los patrones
encaja, el símbolo se considerará nuevo.
A pattern is considered lost if it does not match any symbol in the library. By default
this will trigger a dpkg-gensymbols failure under -c1 or higher level. However, if the
failure is undesired, the pattern may be marked with the optional tag. Then if the pattern
does not match anything, it will only appear in the diff as MISSING. Moreover, like any
symbol, the pattern may be limited to the specific architectures with the arch tag. Please
refer to Standard symbol tags subsection above for more information.
Patterns are an extension of the deb-symbols(5) format hence they are only valid in symbol
file templates. Pattern specification syntax is not any different from the one of a
specific symbol. However, symbol name part of the specification serves as an expression to
be matched against name@version of the real symbol. In order to distinguish among
different pattern types, a pattern will typically be tagged with a special tag.
A día de hoy, dpkg-gensymbols es compatible con tres tipos de patrones básicos:
c++
Este patrón se indica con la etiqueta c++. Sólo encaja con el nombre «demangled» de
símbolos C++ (tal y como muestra la herramienta c++filt(1)). Este patrón es de utilidad
para emparejar símbolos con nombres «mangled» que pueden variar según la arquitectura,
mientras que sus nombres «demangled» permanecen sin cambios. Un grupo de estos símbolos
son los thunk no virtuales, que tienen direcciones relativas («offsets») específicas a
la arquitectura integradas en sus nombres «mangled». Un ejemplo común de este caso es
un destructor virtual, que bajo una herencia de diamante necesita un símbolo thunk no
virtual. Por ejemplo, incluso si «_ZThn8_N3NSB6ClassDD1Ev@Base» en arquitecturas de
32bit es «_ZThn16_N3NSB6ClassDD1Ev@Base» en arquitecturas de 64bit, puede emparejarlo
con un único patrón c++:
libdummy.so.1 libdummy1 #MINVER#
[...]
(c++)"non-virtual thunk to NSB::ClassD::~ClassD()@Base" 1.0
[...]
Puede obtener el nombre «demangled» del ejemplo anterior ejecutando la siguiente orden:
$ echo '_ZThn8_N3NSB6ClassDD1Ev@Base' | c++filt
Observe que aunque el nombre «mangled» sea por definición único en la biblioteca, no es
necesariamente cierto para nombres «demangled». Puede que dos símbolos reales y
distintos tengan el mismo nombre «demangled». Por ejemplo, en caso de existir símbolos
thunk no virtuales en complejas configuraciones de herencia, o con la mayoría de
constructores y destructores (ya que habitualmente g++ genera dos símbolos para ellos).
Por otra parte, estas colisiones aparecen al nivel de la ABI, y por ello no deberían
degradar la calidad del fichero de símbolos.
symver
La etiqueta symver indica este patrón. Las bibliotecas bien mantenidas tienen símbolos
con versión, donde cada versión corresponde con la versión del autor original en la que
se añadió el símbolo. De ser así, puede utilizar un patrón symver para emparejar el
símbolo asociado con una versión en particular. Por ejemplo:
libc.so.6 libc6 #MINVER#
(symver)GLIBC_2.0 2.0
[...]
(symver)GLIBC_2.7 2.7
access@GLIBC_2.0 2.2
Todos los símbolos asociados con las versiones «GLIBC_2.0» y «GLIBC_2.7» llevan a una
versión mínima de 2.0 y 2.7 respectivamente, con la excepción del símbolo
«access@GLIBC_2.0». El segundo lleva a una dependencia mínima sobre la versión 2.2 de
libc6, a pesar de estar en el rango del patrón «(symver)GLIBC_2.0», debido a que los
símbolos específicos tiene precedencia sobre los patrones.
Tenga en cuanta que los patrones de comodín antiguos (indicados por «*@versio» en el
campo del nombre del símbolo) son aún compatibles, aunque han quedado obsoletos por el
nuevo estilo de sintaxis «(symver|optional)versión». Por ejemplo, debería escribir
«*@GLIBC_2.0 2.0» como «(symver|optional)GLIBC_2.0 2.0» si desea el mismo
comportamiento.
regex
Los patrones de expresiones regulares se indican con la etiqueta regex. Buscan
coincidencias con la expresión regular de perl definido en el campo de nombre del
símbolo. Una expresión regular se empareja tal cual, por ello no olvide insertar ^ al
inicio de la misma o puede que coincida con cualquier parte de la cadena real del
símbolo nombre@versión. Por ejemplo:
libdummy.so.1 libdummy1 #MINVER#
(regex)"^mystack_.*@Base$" 1.0
(regex|optional)"private" 1.0
Los símbolos como «mystack_new@Base», «mystack_push@Base», «mystack_pop@Base» y
similares encajarían con el primer patrón, mientras que otros como
«ng_mystack_new@Base» no lo harían. El segundo patrón encaja con todos los símbolos con
«private» en su nombre, y las coincidencias heredarán de este patrón la etiqueta
optional.
Puede combinar los patrones listados anteriormente, cuando tenga sentido. En tal caso, se
procesan en el orden de las etiquetas definidas. Por ejemplo, ambos
(c++|regex)"^NSA::ClassA::Private::privmethod\d\(int\)@Base" 1.0
(regex|c++)N3NSA6ClassA7Private11privmethod\dEi@Base 1.0
encaja con «_ZN3NSA6ClassA7Private11privmethod1Ei@Base» y
«_ZN3NSA6ClassA7Private11privmethod2Ei@Base». Al comparar el primer patrón se «demangle»
el símbolo sin procesar como símbolo C++, para después comparar el nombre «demangled» con
la expresión regular. Por otra parte, al comparar el segundo patrón la expresión regular
se compara con el nombre sin procesar del símbolo, para después confirmar si es un símbolo
de C++ mediante «demangle». Un fallo de un patrón básico lleva a un fallo de todo el
patrón. Por ejemplo, «__N3NSA6ClassA7Private11privmethod\dEi@Base» no encajaría con ningún
patrón porque no es un símbolo válido de C++.
En general, todos los patrones se dividen en dos grupos: aliases (los básicos c++ y
symver) y patrones genéricos (regex, todas las combinaciones de varios patrones básicos).
Establecer coincidencias con patrones basados en alias es rápido (0(1)) mientras que los
patrones genéricos son 0(N) (N - cuenta genérica del patrón) para cada símbolo. Debido a
ello, se recomienda no abusar de los patrones genéricos.
Los alias (primero c++, después symver) tienen prioridad sobre los patrones genéricos.
Éstos se emparejan por orden de aparición en la plantilla del fichero de símbolos hasta el
primer resultado de éxito. Tenga en cuenta, no obstante, que no se recomienda la
reorganización manual de las entradas en plantillas de fichero ya que dpkg-gensymbols
genera «diffs» basados en el orden alfanumérico de sus nombres.
Usar «include»
Hay casos en los que utilizar un sólo fichero de símbolos es contraproducente cuando el
conjunto de símbolos exportados difiere según la arquitectura. En estos casos, una
directiva «include» puede ser útil de un par de maneras:
• Puede factorizar la parte común en algún fichero externo, e incluir ese fichero en su
fichero paquete.symbols.arq usando una directiva «include» como esta:
#include "packages.symbols.common"
• Al igual que con cualquier símbolo, puede etiquetar la directiva «include»:
(etiqueta|...|etiquetaN)#include "fichero-para-include"
Como resultado, se considerará que todos los símbolos incluidos en
fichero-para-include están etiquetados con etiqueta ... etiquetaN por omisión. Puede
utilizar esta característica para crear un fichero común package.symbols, que incluye
ficheros de símbolos específicos a la arquitectura.
common_symbol1@Base 1.0
(arch=amd64 ia64 alpha)#include "package.symbols.64bit"
(arch=!amd64 !ia64 !alpha)#include "package.symbols.32bit"
common_symbol2@Base 1.0
Los ficheros de símbolos se leen línea a línea, y las directivas «include» se procesan por
orden de aparición. Esto significa que el contenido del fichero incluido puede sustituir
cualquier contenido aparecido antes de la directiva «include», y que todo contenido a
continuación de la directiva puede sustituir cualquier contenido del fichero incluido.
Todo símbolo (o incluso otra directiva «#include») en el fichero incluido puede
especificar etiquetas adicionales, o sustituir valores de las etiquetas heredadas en la
especificación de etiqueta. Por otra parte, el símbolo no puede eliminar ninguna de las
etiquetas heredadas.
Un fichero incluido puede repetir la línea de cabecera que contiene el «SONAME» de la
biblioteca. En tal caso, sustituye cualquier línea de cabecera leída anteriormente. Por
otra parte, generalmente es mejor evitar duplicar las líneas de cabecera. A continuación
puede ver una manera de realizar esto:
#include "libsomething1.symbols.common"
arch_specific_symbol@Base 1.0
Buena gestión de bibliotecas
Una biblioteca mantenida adecuadamente tiene las siguientes características:
• su API es estable (los símbolos públicos nunca se eliminan, sino que sólo se añaden
símbolos nuevos), y los cambios pueden introducir una incompatibilidad sólo cuando el
«SONAME» cambia;
• Idealmente, usa el versionado de símbolos para alcanzar la estabilidad de la ABI, a
pesar de cambios internos y la extensión de la API;
• No exporta símbolos privados (tales como símbolos etiquetados como opcionales para
evitar un problema).
Al mantener un fichero «symbols» es sencillo notar la aparición y desaparición de
símbolos. Pero es más difícil notar cambios incompatibles en las API y ABI. Por ello, el
responsable del paquete debería leer cuidadosamente el registro de cambios de la fuente
original en busca de casos en los que se ha roto la correcta gestión de bibliotecas. Se
debería notificar al autor original en caso de encontrar problemas potenciales, ya que un
arreglo en la fuente original del software es siempre preferible a un arreglo específico
de Debian.
OPCIONES
-Pdirectorio-compilación-paquete
Analiza directorio-compilación-paquete en lugar de «debian/tmp».
-ppaquete
Define el nombre del paquete. Es necesario si aparece más de un paquete binario en
«debian/control» (o si no existe ningún fichero «debian/control»).
-vversión
Define la versión del paquete. El valor por omisión es la versión extraída de
«debian/changelog». Necesario en caso de una ejecución externa al árbol del paquete
fuente.
-efichero-biblioteca
Only analyze libraries explicitly listed instead of finding all public libraries.
You can use shell patterns used for pathname expansions (see the File::Glob(3perl)
manual page for details) in library-file to match multiple libraries with a single
argument (otherwise you need multiple -e).
-Inombre-fichero
Usa nombre-fichero como un fichero de referencia para generar el fichero «symbols»
integrado en el mismo paquete.
-O[filename]
Print the generated symbols file to standard output or to filename if specified,
rather than to debian/tmp/DEBIAN/symbols (or package-build-dir/DEBIAN/symbols if -P
was used). If filename is pre-existing, its contents are used as basis for the
generated symbols file. You can use this feature to update a symbols file so that
it matches a newer upstream version of your library.
-t Write the symbol file in template mode rather than the format compatible with
deb-symbols(5). The main difference is that in the template mode symbol names and
tags are written in their original form contrary to the post-processed symbol names
with tags stripped in the compatibility mode. Moreover, some symbols might be
omitted when writing a standard deb-symbols(5) file (according to the tag
processing rules) while all symbols are always written to the symbol file template.
-c[0-4]
Define las comprobaciones a realizar al comparar el fichero «symbols» generado
usando como base el fichero de plantilla. El nivel predefinido es 1. Aumentar los
niveles conlleva más comprobaciones, así como la inclusión de todos los niveles
inferiores. El nivel 0 nunca falla. El nivel 1 falla si algunos símbolos han
desaparecido. El nivel 2 falla si se han introducido símbolos nuevos. El nivel 3
falla si han desaparecido algunas bibliotecas. El nivel 4 falla si se han
introducido bibliotecas nuevas.
This value can be overridden by the environment variable
DPKG_GENSYMBOLS_CHECK_LEVEL.
-q Keep quiet and never generate a diff between generated symbols file and the
template file used as starting point or show any warnings about new/lost libraries
or new/lost symbols. This option only disables informational output but not the
checks themselves (see -c option).
-aarquitectura
Toma arquitectura como la arquitectura anfitrión al procesar ficheros «symbols».
Use esta opción para generar un fichero «symbols» o un «diff» para cualquier
arquitectura, siempre y cuando sus binarios ya estén disponibles.
-d Activa el modo de depuración. Se muestran numerosos mensajes que explican las
acciones de dpkg-gensymbols.
-V Activa el modo verboso. El fichero «symbols» generado contiene símbolos obsoletos
en la forma de comentarios. Además, en modo plantilla los patrones de símbolo
anteceden a los comentarios que listan los símbolos reales que coinciden con el
patrón.
-?, --help
Muestra el modo de uso y termina.
--version
Muestra la versión y termina.
VÉASE TAMBIÉN
https://people.redhat.com/drepper/symbol-versioning
https://people.redhat.com/drepper/goodpractice.pdf
https://people.redhat.com/drepper/dsohowto.pdf
deb-symbols(5), dpkg-shlibdeps(1).
TRADUCTOR
Rudy Godoy <rudy@kernel-panik.org>, Rubén Porras <nahoo@inicia.es>, Bruno Barrera C.
<bruno.barrera@igloo.cl>, Carlos Izquierdo <gheesh@ertis.net>, Esteban Manchado y NOK.
Debian L10n Spanish <debian-l10n-spanish@lists.debian.org>.
Revisiones por Santiago Vila <sanvila@unex.es>, Javier Fernández-Sanguino, Rubén Porras,
Luis Uribe y Omar Campagne.