Provided by: dpkg-dev_1.16.1.2ubuntu7_all bug

NOMBRE

       dpkg-gensymbols  -  Generación  de  ficheros  «symbols»  (información  de  dependencia  de
       bibliotecas compartidas)

SINOPSIS

       dpkg-gensymbols [option...]

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, usando el primero que encuentra.

       ·   debian/package.symbols.arch

       ·   debian/symbols.arch

       ·   debian/package.symbols

       ·   debian/symbols

       La meta principal de estos ficheros es proporcionar la  versión  mínima  asociada  a  cada
       símbolo  proporcionado  por  las bibliotecas. Habitualmente, se corresponde con la primera
       versión de ese paquete  que  proporciona  el  símbolo,  pero  el  desarrollador  lo  puede
       incrementar manualmente si la ABI del símbolo se extiende sin romper la compatibilidad con
       versiones anteriores. Es la responsabilidad del desarrollador que estos ficheros estén  al
       día y que sean apropiados, pero dpkg-gensymbols le asiste en esta tarea.

       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»

       Los ficheros «symbols» son realmente útiles sólo cuando reflejan la evolución del  paquete
       a  lo  largo  de  varias publicaciones. Por ello, el desarrollador tiene que actualizarlos
       cada vez que se añada un símbolo nuevo, para que así la mínima versión asociada  concuerde
       con  la  realidad.  Para hacer esto apropiadamente puede usar los «diff» contenidos en los
       registros de construcción. En la mayoría de los caso, el  «diff»  se  aplica  directamente
       sobre  el  fichero «debian/package.symbols». Dicho esto, es necesario afinar este proceso:
       se recomienda, por ejemplo, eliminar el número de revisión de Debian de la versión  mínima
       para  que  así  aquellas  adaptaciones  hacia atrás («backports») con un número de versión
       menor,  pero  con  la  misma  versión  que  la  fuente  original,  puedan  satisfacer  las
       dependencias generadas. Si no se puede eliminar la revisión de Debian porque el símbolo se
       añadió debido a un cambio específico de Debian puede afijar «~» a la versión.

       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.

   Usar la sustitución de #PACKAGE#
       En algunos casos aislados el nombre de la biblioteca varía según  la  arquitectura.  Puede
       usar  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
       El etiquetado de símbolos es útil para marcar aquellos símbolos que son de  alguna  manera
       especiales.  Cada  símbolo puede tener un número arbitrario de etiquetas asociadas a éste.
       Aunque se analizan y guardan todas las etiquetas, dpkg-gensymbols sólo entiende algunas de
       ellas,  e  iniciará  un  tratamiento  especial  de  los  símbolos. Consulte la sub-sección
       Etiquetas estándar de símbolos para una referencia de estas etiquetas.

       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.

       Debido  a  que las etiquetas de símbolos son una extensión del formato deb-symbols(5) sólo
       pueden formar parte de los ficheros «symbols» de paquetes fuente (estos ficheros  deberían
       aparecer como plantillas usadas para generar los ficheros «symbols» integrados en paquetes
       binarios). Cuando invoca dpkg-gensymbols con la opción -t, enviará por la salida  ficheros
       «symbols» compatibles con el formato deb-symbols(5): procesa completamente los símbolos de
       acuerdo a los requerimientos de sus etiquetas estándar, y elimina todas las  etiquetas  de
       la  salida.  Por  otra  parte,  en  el modo plantilla (-t), todos los símbolos y etiquetas
       (estándar y desconocidos) se muestran por la salida, y se escriben en su forma original  a
       medida que se cargan.

   Etiquetas de símbolo estándar
       optional
              Un  símbolo  marcado  como opcional puede desaparecer de la biblioteca en cualquier
              momento sin causar un fallo  de  dpkg-gensymbols.  Por  otra  parte,  los  símbolos
              opcionales  desaparecidos  aparecerán  continuamente como «MISSING» (ausente) en el
              «diff» de cada nueva revisión  del  paquete.  Este  comportamiento  sirve  como  un
              recordatorio  para  el  desarrollador para informar de la necesidad de eliminar tal
              símbolo del fichero «symbols», o de añadir éste nuevamente a la biblioteca.  Cuando
              el  símbolo opcional declarado previamente como «MISSING» reaparece de súbito en la
              siguiente revisión, se actualizara a un estado «existente» sin modificar la versión
              mínima.

              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 usar para
              indicar porqué el símbolo se considera opcional.

       arch=lista-de-arquitecturas
              Esta etiqueta permite limitar el conjunto de arquitecturas dónde se supone  que  el
              símbolo  existe.  Cuando  la  lista  de  símbolos  se  actualiza  con  los símbolos
              descubiertos en la biblioteca, todos los símbolos específicos  de  la  arquitectura
              que  no  son relevantes para la arquitectura anfitrión se toman como no existentes.
              Si un símbolo específico a  la  arquitectura  que  concuerda  con  la  arquitectura
              anfitrión  presente  no  existe  en  la biblioteca, se aplicarán los procedimientos
              normales para símbolos desaparecidos, llevando a  que  dpkg-gensymbols  falle.  Por
              otra  parte,  si  el  símbolo  específico  a la arquitectura se encuentra cuando se
              suponía que no existe (porque la arquitectura anfitrión presente no está listada en
              la  etiqueta),  pasa  a  ser  neutral a la arquitectura (por ejemplo, se elimina la
              etiqueta de  arquitectura,  apareciendo  el  símbolo  en  el  «diff»  debido  a  la
              modificación), pero no se toma como un nuevo símbolo.

              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».

              El  formato  de  lista-de-arquitecturas  es  el  mismo  que  el  usado  en el campo
              Build-Depends de debian/control (a excepción de los paréntesis cuadrados de  cierre
              «[]»).  Por  ejemplo,  el  primer símbolo de la lista a continuación se considerará
              sólo en las arquitecturas alpha, amd64, kfreebsd-amd64  y  ia64,  mientras  que  el
              segundo en todos menos armel.

               (arch=alpha amd64 kfreebsd-amd64 ia64)un_símbolo _específico_64bit@Base 1.0
               (arch=!armel)símbolo_que_armel_no_tiene@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.

       Un patrón se considera perdido si no encaja con  ningún  símbolo  en  la  biblioteca.  Por
       omisión, esto accionará un fallo de dpkg-gensymbols bajo -c1 o un nivel superior. Aun así,
       si no desea la aparición del fallo, puede marcar  el  patrón  con  la  etiqueta  optional.
       Entonces,  si  el  patrón  no  encaja  con  nada  simplemente  aparecerá en el «diff» como
       «MISSING». Aún más, al igual que con cualquier símbolo, puede limitar  el  patrón  a  unas
       arquitecturas  definidas  con  la etiqueta arch. Consulte la sección anterior Etiquetas de
       símbolo estándar.

       Los patrones son una extensión del formato deb-symbols(5), y por ello sólo son válidos  en
       plantillas  de  fichero  de  símbolos.  Por  otra  parte,  la parte del nombre del símbolo
       definido sirve como una expresión que se comparará con el nombre@versión del símbolo real.
       Para   poder  distinguir  entre  los  diferentes  tipos  de  patrón,  éste  se  etiquetará
       habitualmente con una etiqueta especial.

       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 usar 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 usar 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»:

           (tag|..|tagN)#include "file-to-include"

           As a result, all symbols included from file-to-include will be considered to be tagged
           with  tag  ..  tagN  by  default.  You  can  use  this  feature  to  create  a  common
           package.symbols file which includes architecture specific symbol files:

             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  invocación  externa al árbol del
              paquete fuente.

       -efichero-biblioteca
              Sólo analiza las bibliotecas listadas explícitamente, en lugar de buscar todas  las
              bibliotecas  públicas.  Puede usar una expresión regular en fichero-biblioteca para
              emparejar varias bibliotecas con un único argumento (de otra forma, necesita varias
              -e).

       -Inombre-fichero
              Usa  nombre-fichero como un fichero de referencia para generar el fichero «symbols»
              integrado en el mismo paquete.

       -O     Muestra por  la  salida  estándar  el  fichero  «symbols»  generado,  en  lugar  de
              almacenarlo en el árbol de construcción del paquete.

       -Ofichero
              Guarda  el  fichero  de  símbolos generado como fichero. Si el fichero ya existe su
              contenido se usará como base para el fichero «symbols» generado.  Puede  usar  esta
              característica  para  actualizar  un  fichero  «symbols»  para que coincida con una
              versión más reciente de la biblioteca del autor original.

       -t     Escribe el fichero «symbols» en modo plantilla en lugar del formato compatible  con
              deb-symbols(5).  La  diferencia más notable es que en modo plantilla los nombres de
              símbolo y etiquetas se escriben en su forma original, en lugar de  los  nombres  de
              símbolo  post-procesados  con  las etiquetas eliminadas en modo compatible. Además,
              puede  que  se  omitan  algunos  símbolos  al  escribir  un  fichero  estándar   de
              deb-symbols(5)  (de  acuerdo  a las reglas de procesamiento de etiquetas), mientras
              que siempre se insertan todos los símbolos en el modo plantilla.

       -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.

              Puede    sustituir    este     valor     con     la     variable     de     entorno
              «DPKG_GENSYMBOLS_CHECK_LEVEL».

       -q     No  muestra informes y nunca genera un «diff» entre el fichero «symbols» generado y
              el fichero de plantilla tomado como  base,  ni  muestra  ningún  aviso  relativo  a
              bibliotecas  nuevas  o  ausentes,  o  símbolos  nuevos o ausentes. Esta opción solo
              desactiva la salida informativa, pero no las  comprobaciones  (consulte  la  opción
              -c).

       -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.

       -h, --help
              Muestra el modo de uso y termina.

       --version
              Muestra la versión y termina.

VÉASE TAMBIÉN

       http://people.redhat.com/drepper/symbol-versioning
       http://people.redhat.com/drepper/goodpractice.pdf
       http://people.redhat.com/drepper/dsohowto.pdf
       deb-symbols(5), dpkg-shlibdeps(1).

AUTORES

       Copyright © 2007-2009 Raphaël Hertzog

       Esto  es  software  libre; vea la versión 2 o posterior de la Licencia Pública General GNU
       para condiciones de copia. NO hay ninguna garantía.

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.