linker - Comprender las importaciones de paquetes en el archivo.cbproj

c++builder c++builder-2010

Question

Estoy usando Embarcadero RAD Studio 2010 (C ++). El archivo de proyecto (.cbproj) tiene cinco etiquetas diferentes que contienen listas de .bpis o .libs. Me gustaría obtener información sobre cómo el enlazador usa cada una de estas listas de archivos de biblioteca (cuando compila con o sin paquetes de tiempo de ejecución).

LinkPackageImports

LinkPackageStatics

AllPackageLibs

PackageLibs

PackageImports
Creo que ya entiendo esto último. Contiene la lista de paquetes de tiempo de ejecución que se pueden establecer desde las Propiedades del proyecto en el IDE.

La motivación para esta pregunta es que estoy tratando de eliminar dependencias innecesarias de mi aplicación. Estas cinco etiquetas en .cbproj parecen contener cada una una variedad arbitraria de diferentes libs y bpis. Algunas de las bibliotecas que sé que no necesito, y algunas de las bibliotecas, creo que no las necesito. La eliminación de algunas bibliotecas de algunas de las listas parece no tener ningún efecto, mientras que eliminar otras bibliotecas de otras listas provoca errores de enlazador del formulario [ILINK32 Error] Fatal: Unable to open file ''FILENAME.OBJ''

Poco a poco voy resolviendo todos los problemas del vinculador, pero sería realmente útil saber exactamente lo que le digo al vinculador que haga cuando incluyo el nombre de una biblioteca en una de estas cinco listas.

Answer 1

Hombre, espero que ya haya encontrado la solución para sus problemas, pero creo que solo tiene que deshabilitar Build With Runtime Packages, deshabilitar Use Dynamic RTL y cambiar de Debug a Release build, para todos los proyectos que esté utilizando ( http: // bcbjournal.org/articles/vol4/0009/Building_stand-alone_EXEs.htm?PHPSESSID=08f2084c32d5fce05f13518fef23f358 ).

Si tiene algunos componentes que no puede cambiar, como algunos binarios (dll, lib ...), todavía estaría con algunas dependencias en las opciones deshabilitadas si se han creado previamente con ellos ...

También sugiero que elimine todos los * .obj y * .exe de su proyecto (excepto si se proporcionan como requisito para algunos módulos de terceros) antes de compilar ... Algunas versiones anteriores de C ++ Builder tienen algunos problemas de compilación que se resuelven en ese camino.

Answer 2

Estoy seguro de que esta información debe existir en alguna parte, pero no he podido encontrarla en ningún foro o documentación. Deduje todo esto de mi propia experimentación, pero agradecería los comentarios de una fuente más oficial.

PackageImports : aparece como la lista "Paquetes de tiempo de ejecución" en Opciones de proyecto en el IDE. Si agrega o elimina algo de la lista "Paquetes de tiempo de ejecución" en el IDE, esta etiqueta se actualizará para reflejar eso. Si esta etiqueta está vacía o falta en el archivo cbproj, se completará automáticamente con una lista de todos los paquetes de tiempo de ejecución asociados con todos los paquetes de tiempo de diseño instalados en RAD Studio. Esta etiqueta no tiene efecto cuando se construye desde la línea de comando. El IDE parece usar la etiqueta PackageImports solo para calcular las bibliotecas que realmente va a vincular.

Colocar una biblioteca en esta lista no crea (por sí mismo) nuevas dependencias; básicamente le está diciendo al IDE: "Si tiene que vincular cualquiera de estas bibliotecas, vincúlelas dinámicamente en vez de estáticamente".

AllPackageLibs : esta es la lista del IDE de todas las bibliotecas que cree que son necesarias para que el proyecto se vincule con éxito. Esta etiqueta no tiene efecto cuando se construye desde la línea de comando. Si realiza un cambio en el proyecto (por ejemplo, agrega un archivo), el IDE intentará volver a calcular los contenidos de AllPackageLibs. Lo calcula a partir del #pragma link que encuentra en los archivos del proyecto. (Lo determiné comentando todos los #pragma link del proyecto y notando que AllPackageLibs no se volvió a llenar cuando realicé una modificación del proyecto).

LinkPackageStatics : si el IDE encuentra una biblioteca en AllPackageLibs que no aparece en PackageImports, decide vincular estáticamente esa biblioteca. En ese caso, el IDE copiará automáticamente el nombre de la biblioteca a LinkPackageStatics. Si compila desde el IDE, esta etiqueta siempre se volverá a calcular desde AllPackageLibs y PackageImports, por lo que el enlazador ignorará todo lo que agregue aquí manualmente. Sin embargo, si se construye desde la línea de comandos, todos los archivos en esta etiqueta (.libs o .bpis) se vincularán y aparecerán en la sección ''objfiles'' de la línea de comando de ilink32.

LinkPackageImports : si el IDE encuentra una biblioteca en AllPackageLibs que aparece en PackageImports, decide vincular dinámicamente esa biblioteca. En ese caso, el IDE copiará el nombre de la biblioteca (con una extensión .bpi) a LinkPackageImports. Si compila desde el IDE, esta etiqueta siempre se volverá a calcular desde AllPackageLibs y PackageImports, por lo que el enlazador ignorará todo lo que agregue aquí manualmente. Sin embargo, si se construye desde la línea de comandos, todos los archivos en esta etiqueta (.libs o .bpis) se vincularán y aparecerán en la sección ''libfiles'' de la línea de comandos de ilink32.

PackageLibs : todo lo que se encuentre en PackageLibs (.libs o .bpis) será agregado directamente a LinkPackageStatics por el IDE (independientemente de lo que contenga PackageImports). Estas bibliotecas se agregan a LinkPackageStatics en frente de las librerías que vienen de AllPackageLibs. Las compilaciones de línea de comandos no se ven afectadas por esta etiqueta.

Cada vez que espere que el IDE modifique LinkPackageStatics o LinkPackageImports por usted, primero deberá compilar el proyecto en el IDE; luego haga un pequeño cambio en las opciones del proyecto (y deshagalo); luego guarda el proyecto En este punto, el IDE escribirá LinkPackageStatics o LinkPackageImports en cbproj para que su proyecto pueda vincularse en la línea de comando.

Otras formas de vincular libaries : también hay un par de formas para especificar los archivos que se vincularán y que no implican estas cuatro etiquetas. Puede agregar .lib directamente al proyecto (haga clic derecho en el proyecto | Agregar ...), o puede insertar la línea #pragma comment (lib, "libraryname.lib") en uno de los archivos compilados con el proyecto.

Si agrega .lib directamente al proyecto, aparecerá en la línea de comandos con todas las demás bibliotecas que se vincularán. Si usa el truco de #pragma comment , la biblioteca no aparecerá en la línea de comandos, y no podrá ver que estaba vinculada (excepto al usar tdump y mirar las exportaciones).

Resumen

Al vincular desde la línea de comandos, las únicas etiquetas cbproj (de estas cinco) que tienen algún efecto son LinkPackageStatics (libs para agregar a la sección objfiles) y LinkPackageImports (libs para agregar a la sección libfiles). El contenido de estas etiquetas se calcula mediante el IDE de AllPackageLibs y PackageImports, pero puede establecerlas manualmente en .cbproj si necesita vincular desde la línea de comandos.

Cuando se vincula desde el IDE, generalmente querrá que el IDE administre sus bibliotecas por usted. Si necesita agregar una biblioteca que el IDE no detecta automáticamente, debe abrir el archivo .cbproj en un editor externo y agregar la biblioteca faltante a la etiqueta AllPackageLibs. Si desea que la biblioteca esté vinculada dinámicamente, también debe agregar el nombre de la biblioteca a la lista "Crear con paquetes de tiempo de ejecución" (también conocido como PackageImports).

Si quiere asegurarse de vincular dinámicamente todas sus bibliotecas, mire la etiqueta LinkPackageStatics en el archivo .cbproj. Si hay bibliotecas en esa lista, están siendo vinculadas estáticamente. Para solucionar esto, copie los nombres de esas bibliotecas en la etiqueta PackageLibs (y cambie sus extensiones a bpi); luego elimine la etiqueta LinkPackageStatics.