c++ - ubicacion - obligar a Visual Studio a vincular todos los símbolos en un archivo lib

pdb visual studio

Question

¿Hay alguna forma de obligar a Visual Studio a vincular todos los símbolos de un archivo lib a la DLL como ATM? Está optimizando las funciones "no utilizadas" que necesita el programa que utiliza el dll en tiempo de ejecución.

Intenté usar / OPT: NOREF y / OPT: NOICF pero parece que no funcionan.

La razón por la que los necesito es porque son clase global que se registran a sí mismos con un controlador y no están vinculados en el dll.

Answer 1

¿Cómo va a llamar el DLL a las funciones de su lib en tiempo de ejecución? Eso suena un poco difícil de creer.

Ahora, si los usuarios de la DLL van a llamar a las funciones de su biblioteca, su pregunta tiene sentido. Los compiladores de Windows (a diferencia de los compiladores de Unix) solo exportan funciones de una DLL si se solicita explícitamente. La forma más común de hacer esto es declarar la función "dllexport", pero también puede nombrar las funciones en un archivo .DEF para pasarlo al enlazador. Tenga en cuenta que debe enumerar el nombre anulado de C ++ en el archivo .DEF.

Answer 2

En realidad, hay una solución medio oficial para ello, y aquí está .

TL; DR:

''Usar entradas de dependencia de biblioteca'' .

En VS lingo ''library dependence inputs'' es un nombre para los archivos obj que constituyen una biblioteca. En realidad, puedes controlar este comportamiento en dos ámbitos:

1. Por referencia: por el combo ''use library dependency inputs'' en las propiedades de referencia. Esta es la solución que utilicé personalmente, y la mencionada en la publicación .

2. Por todo el archivo ejecutable: en las propiedades del proyecto exe / C ++ / Linker / General / Usar las entradas de dependencia de la biblioteca -> Sí

La motivación histórica para estas configuraciones arcanas es habilitar la vinculación incremental en lugares donde antes no estaba disponible , pero tiene el efecto secundario útil de vincular directamente con los archivos obj que están empaquetados en una lib, y así construir también objetos globales sin referencia.

Answer 3

No sé si hay una manera más elegante en Visual Studio, pero la solución multiplataforma que utilizamos tiene dos macros que fuerzan al archivo de objeto problamatic a vincularse.

Uno se coloca en el archivo de origen de las funciones que se excluyen, el otro se coloca en una función que el vinculador sabe que se llamará.

Algo como;

#define FORCE_LINK_THIS(x) int force_link_##x = 0;
#define FORCE_LINK_THAT(x) { extern int force_link_##x; force_link_##x = 1; }

No es exactamente elegante, pero no hemos encontrado una mejor solución que funcione en todas las plataformas.

Answer 4

Probado en MSVC2k17 ...

__pragma(comment(linker,"/export:REGISTERfunc"));
void REGISTERfunc() { printf("I''m linked!/n" ); }

Totalmente funciona. ¡Esto incluso puede estar dentro de un archivo .lib estáticamente enlazado y continuará hasta el ejecutable de salida y más allá!

EDITAR: ¡Incluso puedes ponerlo en una macro para obtener puntos increíbles!

EDITAR: Otra nota: debe habilitar código de tiempo de enlace habilitado. / LTCG ... algo

Answer 5

Tuve el mismo problema con un sistema de complementos en el que las fábricas de varios archivos DLL usaban una fábrica principal común, todo lo que se registraba al iniciar al cargar bibliotecas, sin tener que compilar con fuerza la lista de complementos que se utilizarían. Esto funcionaba muy bien en Linux pero tenía dos problemas en Windows:

1. las fábricas no eran comunes entre las DLL. Este no es tu problema pero está relacionado. Aquí tengo una solución: asegurar el uso de los fatories comunes . Mira la respuesta de James con la función set_the_global.

2. no se configuraron al inicio si no se usaba ningún símbolo de la DLL en general. Creo que es tu problema La única solución que encontré fue usar archivos de configuración (uno por subproyecto) que enumera los nombres de los complementos (DLL) disponibles y forzar su vinculación utilizando, en mi caso, QLibrary. Con cmake, se genera una versión predeterminada de un archivo de configuración para cada subproyecto durante el tiempo de compilación utilizando la siguiente macro, llamada en lugar de add_library en cada dir de complemento:

   file(WRITE ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}-plugins "")
   macro (DECLARE_AMOSE_PLUGIN _plugin)
   file (APPEND ${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}-plugins "${_plugin}/n")
   add_library(${_plugin} SHARED ${${_plugin}_LIB_SRCS})
   endmacro (DECLARE_AMOSE_PLUGIN)

Answer 6

Usé un pragma, parece funcionar, pero no se estrangula si no incluyes la línea.

#include "library1.h"
#include <QApplication>
#pragma comment(lib, "C://Qt//5.5//msvc2013_64//lib//Qt5Guid.lib")
PHI_STATUS PHI_EXP_CONV PHI_ShowGUI(size_t reserved)
{
QApplication app(none, nullptr);
...
}

También puede vincularlos mediante el campo Additional Dependencies en la pestaña Librarian .