Enlazador El problema: ¿Cómo determinar donde un "/ DEFAULTLIB" viene de

Estoy tratando de encontrar una buena manera de determinar qué módulo en tiempo de enlace está causando una cierta biblioteca para ser procesado como un "/ DEFAULTLIB" como se ve en el resultado del enlazador detallado de Visual Studio.Enlazador El problema: ¿Cómo determinar donde un "/ DEFAULTLIB" viene de

Aquí es mi situación, tengo varios biblioteca estática pre-requisitos y cada uno tiene una liberación y una versión de depuración (BlahD.lib y Blah.lib). Por algún motivo, en el momento del enlace, todas las * D.lib se procesan como bibliotecas predeterminadas, aunque estoy creando una versión con las librerías sin depuración especificadas como "Dependencias Adicionales". Si nunca construyo las versiones de depuración de las bibliotecas estáticas esos archivos * D no existirían y habría un error del enlazador (no se puede abrir el archivo).

puedo conseguir mi proyecto para construir con éxito mediante la especificación/NODEFAULTLIB para todos los archivos .lib estos infractores. Todas las bibliotecas de versiones se conectan y todos están contentos. Pero quiero entender qué está pasando aquí. ¿Qué está causando que estos archivos * D.lib sean procesados por el vinculador? ¿Es mi única esperanza escribir algún tipo de script que dumpbins todo en este proyecto masivo y sus proyectos dependientes (microsoft support)? Incluso entonces, no entiendo qué buscar en la salida del dumpbin, ¿esto se aplica a los archivos .lib así como a los archivos .obj?

Fuente

2011-03-09 insipid

Busque #pragma comment(lib) en la fuente. Ver si tal vez depende de una #define - Esta es una forma común de un SDK para asegurar que las librerías correctas están vinculados, y es posible que necesite definir THESDK_DEBUG o THESDK_RELEASE para la lógica para hacer ejercicio.

Información adicional: descubrí en Visual Studio 2008 que incluso comentando la declaración de la .IDL presentar * no funciona, como en:

//cpp_quote("#pragma comment(lib, \"MYLIB.lib\")")

El compilador agrega todavía MYLIB.LIB como un DEFAULTLIB, y termina en el archivo * .obj. ¡Asegúrate de eliminar completamente la línea del código!

Fuente

2011-03-09 17:17:20 Erik

Tuve un problema similar. Solo pude resolverlo analizando los archivos * .obj como sugirió. Para hacerlo, me encontré con el siguiente comando a través del símbolo de Visual Studio (en la carpeta temporal del proyecto, donde se generan los archivos * .obj):

for /R %1 in (*.obj) do @dumpbin /directives /section:.drectve "%1" > "%1".directives.txt

Luego utiliza Notepad ++ para buscar el nombre de la biblioteca ofensiva en todos estos archivos * .directives.txt. Esto reveló qué proyecto estaba haciendo referencia a la lib incorrecta.

Nota: es posible que desee modificar esto para incluir cualquier tercero-partido * .lib su proyecto puede utilizar, y no sólo los archivos * .obj. Las instrucciones "/ DEFAULTLIB" también pueden provenir de ellos.

Nota: puede que tenga que utilizar * .o en lugar de * .obj Enlace

Fuente

2013-06-03 14:23:01

Si está en un sistema que admite estos comandos, puede buscar los archivos generados fácilmente desde la línea de comandos: find. -name "* .directives.txt" | xargs grep – JamesG

Encontré este método el más útil, aunque encontré más fácil dirigir todos los resultados al mismo archivo que tengo cientos de archivos de objetos en múltiples directorios. Redirigir con >> c: \ directives.txt en su lugar. – Teknogrebo

Parece que las directivas antes mencionadas vienen en texto sin formato dentro de los archivos obj y lib. Por lo tanto, no es necesario llamar a dumpbin.Para mí solo ejecutando lo siguiente desde la línea de comando funcionó: 'findstr/m/s/c:"/DEFAULTLIB: "" mylib * .obj * .lib' –

con la opción /verbose y buscar la salida para el nombre de la biblioteca en cuestión. Esto le indicará qué archivo de objeto arrastró la biblioteca al enlace.

Fuente

2015-06-30 19:35:37

Enlazador El problema: ¿Cómo determinar donde un "/ DEFAULTLIB" viene de

Respuesta

Cuestiones relacionadas