¿Por qué necesito un archivo * .obj al vincular estáticamente?

Question

No estoy seguro de por qué es esto. Estoy distribuyendo un static * .lib en varios proyectos, pero esta lib estática genera muchos archivos * .obj. Parece que necesito distribuir también esos archivos * .obj con * .lib. De lo contrario, aparece este error:

1>LINK : fatal error LNK1181: cannot open input file 'nsglCore.obj' 

¿Por qué es esto? ¿Hay alguna forma de incluir los datos en los archivos * .obj en * .lib? Tal vez un cambio en el compilador?

Esta es mi configuración para la biblioteca estática:

C/C++

/Od /GT /D "WIN32" /D "NDEBUG" /D "_LIB" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /MD /Yu"stdafx.hpp" /Fp"e:\Development\Projects\nsGameLib\Source\Core\Intermediate\nsglCore-Win32-Release.pch" /Fo"e:\Development\Projects\nsGameLib\Source\Core\Intermediate\\" /Fd"e:\Development\Projects\nsGameLib\Source\Core\Intermediate\vc90-Release.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt 

Bibliotecario

/OUT:"e:\Development\Projects\nsGameLib\Source\Core\Output\nsglCore-Win32-Release.lib" /NOLOGO /LTCG 

Esta es mi configuración para el proyecto utilizando la biblioteca estática :

C/C++

/O2 /Oi /I "E:\Development\Projects\nsGameLib\Samples\\DummyEngine\\" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_UNICODE" /D "UNICODE" /FD /EHsc /MD /Gy /Fo"e:\Development\Projects\nsGameLib\Samples\OnlyCore\Intermediate\\" /Fd"e:\Development\Projects\nsGameLib\Samples\OnlyCore\Intermediate\vc90-Release.pdb" /W3 /nologo /c /Zi /TP /errorReport:prompt 

Enlazador

/OUT:"e:\Development\Projects\nsGameLib\Samples\OnlyCore\Output\SampleOnlyCore-Win32-Release.exe" /INCREMENTAL:NO /NOLOGO /LIBPATH:"E:\Development\Projects\nsGameLib\Samples\..\Deployment\Libraries" /MANIFEST /MANIFESTFILE:"e:\Development\Projects\nsGameLib\Samples\OnlyCore\Intermediate\SampleOnlyCore-Win32-Release.exe.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"e:\Development\Projects\nsGameLib\Samples\OnlyCore\Intermediate\SampleOnlyCore-Win32-Release.pdb" /SUBSYSTEM:WINDOWS /OPT:REF /OPT:ICF /LTCG /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT nsglCore kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib 

Answer 1

Creo que su línea de vinculador es incorrecta. La biblioteca debe tener un sufijo .lib. Por lo tanto, nsglCore debe ser nsglCore-Win32-Release.lib o quizás nsglCore-$(TargetPlatform)-$(ConfigurationName).lib o cualquiera que sea la macro expansión correcta.

Answer 2

Ah ... Visual Studio es ser demasiado inteligente para usted

Ir a los proyectos que incluyen la lib, a la derecha haga clic para propiedades

Ir a Propiedades de configuración | Enlazador

En la parte inferior: uso de la biblioteca dependencia Entradas - se establece a no

Ésta es una opción de Visual Studio para agarrar los archivos .obj directamente en lugar de en el archivo .lib. Me imagino que es para evitar el paso de enlace y así acelerar la compilación.

En general, debe establecer el proyecto que crea el archivo lib como una dependencia del proyecto que lo usa (bajo propiedades comunes en esa ventana de propiedades). Luego, activa Dependencias de biblioteca de enlaces. Esto funciona bien en la mayoría de los casos.

Answer 3

Generalmente, las librerías estáticas no generan archivos de objeto. Lo que hace es crear archivos de objeto y colocarlos en una biblioteca, luego el vinculador buscará los archivos de objeto en esas bibliotecas.

Explicaré desde un punto de vista de línea de comandos UNIXy ya que es más fácil de entender (no tengo idea de qué maquinaciones VS hace antes de hacer las cosas básicas).

Una línea de comandos de ejemplo para crear un archivo ejecutable es:

gcc -c -o prog.o prog.c 
gcc -o prog prog.o -L/libdir -lstdc 

La primera línea simplemente crea un archivo objeto de su archivo C.La segunda línea crea el ejecutable tirando ficheros objeto juntos, generalmente siguiendo un conjunto de reglas como:

• Todos archivo .o esté expresamente contemplada están vinculados.
• Una vez hecho esto, busca en las bibliotecas otros objetos que satisfagan los símbolos referenciados pero no definidos.

Por ejemplo, supongamos que su prog.c contenía la línea printf("hello\n");. Eso dará como resultado su archivo prog.o que contiene una referencia al printf que aún no se ha cumplido.

El vinculador buscará en las bibliotecas especificadas hasta que cumpla esa referencia. En este caso se buscará todos los archivos de la forma en que /libdir/libstdc.ext:

• /libdir es de su opción -L (un camino para buscar bibliotecas en).
• /lib es una constante.
• stdc es el nombre de una biblioteca para buscar (de -l).
• ext es una o más extensiones (.a, .so, .sl, etc.).

Una vez que se encuentra el símbolo, ese archivo objeto está vinculado para resolverlo. Esto puede dar como resultado más símbolos insatisfechos que aparecen como /libdir/libstdc.a(printf.o) con una referencia a /libdir/libstdc.a(putch.o).

Su problema particular puede deberse al hecho de que está tratando de vincular el archivo objeto directamente en lugar de buscar en las bibliotecas. VS debe tener opciones de proyecto para especificar archivos de objetos, rutas de búsqueda de biblioteca y nombres de biblioteca (no estoy seguro de esto para las últimas versiones, pero sé que las versiones anteriores de MSVC sí).