2009-09-11 9 views
20

Tengo una colección de archivos de bibliotecas estáticas (.lib), uno de los cuales puede haber sido creado con una versión diferente de Visual Studio. Esto está causando la falla de la generación de código de un proyecto que los vincula con todos ellos. ¿Hay alguna manera de determinar qué versión de Visual Studio se utilizó para compilar una biblioteca estática?¿Hay alguna forma de determinar qué versión de Visual Studio se utilizó para compilar una biblioteca estática?

+3

Una mejor pregunta es qué versión del compilador. Es posible compilar librerías estáticas de C++ sin el uso de Visual Studio. – JaredPar

+0

Bastante justo. En mi caso particular, todos están compilados con * alguna * versión de Visual Studio. Sin embargo, hay una pregunta más general al acecho. –

Respuesta

20

Para las bibliotecas de versiones, es poco probable que pueda determinar la versión.

Para las bibliotecas de depuración, puede utilizar dumpbin:

dumpbin /rawdata:1 library.lib 

El manifiesto de ensamblado debe estar al principio del vertedero y contendrá la versión del CRT la biblioteca requiere, junto con la ruta completa al compilador utilizado para construir la biblioteca.

Para ejecutables y archivos DLL, puede obtener la versión del enlazador utilizando dumpbin; es bajo "HEADER VALUES OPCIONALES"

dumpbin /headers program.exe 

Tal vez alguien sabe de una manera de conseguir la versión de las bibliotecas de liberación; Estoy ciertamente interesado también si lo son.

+0

¿Puede compartir algunos detalles sobre dónde encontrar esta herramienta o si no está disponible de forma predeterminada con la instalación de Visual Studio desde la que podemos obtenerla? –

+0

¿El enfoque 'dumpbin/headers program.exe' tampoco funciona con los archivos binarios de publicación? Lo intenté y funcionó. – stackoverflowwww

5

Siempre he usado algo así como (en una ventana cygwin):

strings -f *.lib | grep 'Visual Studio' 

El compilador se pega la ruta del compilador en la biblioteca en versiones de depuración y la ubicación por defecto del compilador de Visual Studio se encuentra bajo un camino eso incluye el texto 'Visual Studio'.

Así, como James McNellis' respuesta, esto también funciona sólo para versiones de depuración y se restringe aún más a generaciones que realmente utiliza un compilador que se encuentra en un directorio con 'Visual Studio #' en el camino.

Encontré este método hace años con un poco de suerte y todavía no ha fallado.

Tiene la ventaja de que es fácil de recordar si está familiarizado con las herramientas de línea de comandos de Unix.

-2

no ha especificado el idioma, pero en C# la respuesta para saber el sistema operativo y la versión de .NET (en el código en tiempo de ejecución) es:

System.Version osVersion = System.Environment.OSVersion; 
System.Version cliVersion = System.Environment.Version; 

Habría un equivalente en C++ administrada/CLI

Eso no le dirá la verison del compilador o del IDE, pero le dirá el verison de los tiempos de ejecución de .NET. Puede o no necesitar conocer la versión del sistema operativo.

-Jesse

+0

Esto no está ni remotamente relacionado con la pregunta que se hace. Si bien no hay un idioma especificado en la pregunta (que es correcto, dada la pregunta), se trata de bibliotecas estáticas. Las bibliotecas estáticas implican código nativo. La pregunta es, esencialmente, preguntar, qué versión de tiempo de ejecución se compila en el código binario. La versión del sistema operativo no tiene ningún interés aquí. – IInspectable

3

Si tiene los archivos PDB correspondientes a continuación se puede ver la versión del compilador de allí con una herramienta como Pdb Inspector.

O abra el PDB en un visor hexadecimal y busque la cadena "Microsoft (R) Optimizing Compiler".La versión será en cuatro valores de 2 bytes hex justo antes de esa cadena, como en este ejemplo:

000000A060: .. .. .. .. .. .. . ... .. .. .. .. .. .. 13 00    .. 
000000A070: 00 00 6E 5D 00 00 4D 69 63 72 6F 73 6F 66 74 20 ......Microsoft 
000000A080: 28 52 29 20 4F 70 74 69 6D 69 7A 69 6E 67 20 43 (R) Optimizing C 
000000A090: 6F 6D 70 69 6C 65 72 00 .. .. .. .. .. .. .. .. ompiler ........ 

la versión es, pues, HEX 13 00, 00 00, 6E 5D, 00 00, o 19.0.23918.0.

0

Si la biblioteca estática se escribió en C++, y se creó con MSVC 2010 o una versión más reciente, el compilador pudo haber colocado una directiva FAILIFMISMATCH en los archivos del objeto.

No puedo encontrar el documento oficial de Microsoft sobre la directiva FAILIFMISMATCH, pero parece ser utilizado por el vinculador para detectar incompatibilidades entre las versiones de biblioteca estándar de C++.

Usted puede utilizar el siguiente comando para imprimir las directivas de una biblioteca estática:

find "FAILIFMISMATCH" xyz.lib 

(o usar la forma en que mheyman ha mencionado, si usted a favor de cygwin o MSYS)

El resultado puede ser similar a esto:

[email protected] /FAILIFMISMATCH:"_MSC_VER=1900" /FAILIFMISMATCH:"_ITERATOR_DEBUG_LEVEL=0" /FAILIFMISMATCH:"RuntimeLibrary=MD_DynamicRelease" /DEFAULTLIB:"msvcprt" /FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"MSVCRT" /DEFAULTLIB:"OLDNAMES" 

Tenga en cuenta la primera directiva: "_MSC_VER = NNNN". En mi observación, el NNNN siempre coincide con la versión del compilador utilizada para crear el archivo objeto. En mi caso, el xyz.lib se creó con la actualización 3 de MSVC 2015, su versión del compilador C++ es 19.00.24215, por lo que puso/FAILIFMISMATCH: "_ MSC_VER = 1900" en el archivo de objeto.

Se puede encontrar una asignación detallada entre la versión de Visual Studio y la versión del compilador de Microsoft C/C++ at here.

Cuestiones relacionadas