I need to compile a program automatically with different platform toolsets. The compilation is done using cl.exe and link.exe like so:
cl.exe file.c /GS- /PlatformToolset=vc140xp /analyze- /W3 /Gy /Zc:wchar_t /Gm- /Od /Zc:inline /fp:precise /D \"WIN32\" /D \"_WINDOWS\" /D \"_UNICODE\" /D \"UNICODE\" /errorReport:prompt /WX- /Zc:forScope /Gd /Oy- /Oi /MD /Fa\"\" /EHsc /nologo /Fo\"\" /Fp\"\" /diagnostics:classic /link %link_additional% /ENTRY:wWinMain /SUBSYSTEM:WINDOWS /MANIFEST:EMBED /NXCOMPAT /DYNAMICBASE \"kernel32.lib\" \"user32.lib\" \"gdi32.lib\" \"winspool.lib\" \"comdlg32.lib\" \"advapi32.lib\" \"shell32.lib\" \"ole32.lib\" \"oleaut32.lib\" \"uuid.lib\" \"odbc32.lib\" \"odbccp32.lib\" /DEBUG:NONE /MACHINE:%arch% /OPT:REF /SAFESEH /INCREMENTAL:NO /SUBSYSTEM:WINDOWS /MANIFESTUAC:\"level = 'asInvoker' uiAccess = 'false'\" /OPT:ICF /ERRORREPORT:PROMPT /NOLOGO /TLBID:1\
I'm using the switch /PlatformToolset=vc140xp but, the cl.exe doesn't seem to reconginze it, i get an error:
Unknown Option: /PlatformToolset
Is there a way you can change toolset using cl.exe, without msbuild and vcproj ?
Just incase someone need it, i was able to solve this isuue. i added this option to cl.exe:
/D \"_USING_V110_SDK71_\"
And also i modified this option:
/SUBSYSTEM:WINDOWS
to
/SUBSYSTEM:WINDOWS,5.01
After the application runs succesfully on windows xp. You might encounter some problems if you are heavily useing crt in your exe, in my exe i only needed CRT to define Tls callbacks, they do not work without CRT, so i guess maybe this is why this worked for me
Related
I downloaded the source code for a library that resembles the processing library but for c++ called libxd. I used CMake to generate project files for Visual Studio 2019 which worked successfully. When trying to compile the solution for all of the provided build modes, I get the following errors:
The first error invlaid numeric argument '/Wno-narrowing' is what I'm concerned about for now. I'm trying to figure out why this argument is being provided to the compiler. When looking in the properties window for the xd project in the solution I can see the command line arguments that are supposed to be provided to the compiler in the C/C++ > Command Line tab. I verified that there is no /Wno-narrowing option provided. When looking at the build output it can be seen that the option -Wno-narrowing is being provided to the compiler. Can someone help me figure out why this argument is being passed? I looked throughout the compiler properties window to see if I could see anything that would be affecting it but I can't see anything that would affect this.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe /c /IC:\dev\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
Tracking command:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Current\Bin\Tracker.exe /d "C:\Program Files (x86)\MSBuild\15.0\FileTracker\FileTracker32.dll" /i C:\dev\libxd\build\xd.dir\Debug\xd.tlog /r C:\DEV\LIBXD\SRC\OPENSANS.CPP /b MSBuildConsole_CancelEventfa83e1bb599743cfa0c02eb67d579e28 /c "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29910\bin\HostX64\x64\CL.exe" /c /IC:\dev\Users\olive\Downloads\libxd\include /IC:\dev\libxd\lib\glad\include /IC:\dev\libxd\lib\glm /IC:\dev\libxd\lib\stb\include /IC:\dev\libxd\lib\glfw\include /Zi /nologo /W3 /WX- /diagnostics:column /Od /Ob0 /D WIN32 /D _WINDOWS /D "CMAKE_INTDIR=\"Debug\"" /D _MBCS /Gm- /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Zc:inline /GR /Fo"xd.dir\Debug\\" /Fd"xd.dir\Debug\xd.pdb" /Gd /TP /errorReport:prompt -Wno-narrowing C:\dev\libxd\src\opensans.cpp
cl : command line error D8021: invalid numeric argument '/Wno-narrowing'
The command exited with code 2.
The error is caused because that's not a valid MSVC flag. The flag is there because the CMakeLists.txt file demands it:
set_source_files_properties(src/opensans.cpp PROPERTIES COMPILE_FLAGS -Wno-narrowing)
That project specifies what it supports for building under Windows and it's not MSVC.
Windows Prerequisites: mingw-w64 version >= 4.8.1
So you either need to build it in the supported way, or modify the build scripts to allow for MSVC.
That would entail figuring out what the flag does in gcc (disables diagnostic messages about narrowing issues) and finding the equivalent in MSVC, probably a /disable:nnnn variant, once you figure out the nnnn. Figuring that out should be relatively painless since MSVC will tell you that when you compile it - lots of Cnnnn - something to do with narrowing warning messages.
Or you could just disable the line that adds the flag (for MSVC builds only) and see if it still builds. Of course, in the spirit of open source, you should then notify the author what it took to get it going, they may be happy to support MSVC if the effort is not too high.
I'm trying to generate a DLL based on existing software pieces compiled in a static library (.lib) file. I'm using Visual Studio 2019, and the target is purely Windows.
The existing project (P1) have the following function :
int runLocal();
It's compiled to P1.lib.
In my new DLL project (P2), I have the following code :
#include "..\path\to\P1.h" // declaration of "int runLocal()"
extern "C" __declspec(dllexport) int __stdcall DLLMain() {
int res = runLocal();
std::cout << res << std::endl;
}
Project P2 (DLL) have following linker options :
Additional dependencies: D:\path\to\P1.lib;%(AdditionalDependencies)
However the linker "refuse" to see or use the lib file, and I get this error :
LNK2001 unresolved external symbol "int __stdcall runLocal(void)" (?runLocal##YGHXZ).
In fact, I get excatly the same error if I didn't tell the linker to use P1.lib file.
I have control over all the project sources, so I can change stuffs where it's necessary.
Note 1: The P2 project is used by a debug application (a third project compiled separately) that use LoadLibrary() to run the exported DLLMain function.
Note 2: I already succeeded in compiling an exe file against the same .lib file using the same method. So the difference seems to be in the DLL generation.
Note 3: I tried (without success) to play with many options in Visual project properties, in both compiler & linker section, at least the options that are not beyond my understanding.
So, what should I do to link correctly the .lib file and create my dll ?
Edit 1: I add the compiler & linker options:
P1 compiler options:
/permissive- /GS /TP /GL /analyze- /W3 /Gy /Zc:wchar_t
/I"C:\_tools\boost_1_68_0\" /I"C:\_tools\cryptopp_8_2_0\"
/Qspectre /guard:cf /Zi /Gm- /O2 /sdl /Fd"tmp_Win32_Release\p1.pdb" /Zc:inline
/fp:precise /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_CRT_SECURE_NO_WARNINGS"
/D "_UNICODE" /D "UNICODE" /D "_AFXDLL"
/errorReport:prompt /WX- /Zc:forScope /Gd /Oy /Oi /MD /std:c++17 /FC
/Fa"tmp_Win32_Release\" /EHsc /nologo
/Fo"tmp_Win32_Release\" /Ot /Fp"tmp_Win32_Release\p1.pch" /diagnostics:column
P1 librarian options:
/OUT:"D:\Projets\XL4DLL\Common\p1.lib" /LTCG /MACHINE:X86 /SUBSYSTEM:WINDOWS /NOLOGO
Checked with dumpbin.exe as suggested, and the symbol "?runLocal##YGHXZ" exists in p1.lib
P2 compiler options:
/permissive- /MP /GS /TP /GL /analyze- /W3 /Gy /Zc:wchar_t
/I"C:\_tools\boost_1_68_0\" /I"C:\_tools\cryptopp_8_2_0\"
/Qspectre /guard:cf /Zi /Gm- /O2 /sdl /Fd"tmp_Win32_Release\vc142.pdb"
/Zc:inline /fp:precise /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_USRDLL"
/D "_WINDLL" /D "_UNICODE" /D "UNICODE"
/errorReport:prompt /WX- /Zc:forScope /Gz /Oy /Oi /MD /std:c++17 /FC
/Fa"tmp_Win32_Release\" /EHsc /nologo /Fo"tmp_Win32_Release\" /Ot
/Fp"tmp_Win32_Release\XL4DLL32.pch" /diagnostics:column
P2 linker options:
/OUT:"D:\Projets\XL4DLL\Release\XL4DLL32.dll" /MANIFEST /LTCG:incremental
/NXCOMPAT /PDB:"D:\Projets\XL4DLL\Release\XL4DLL32.pdb" /DYNAMICBASE
"D:\Projets\XL4DLL\Common\p1.lib" "D:\Projets\XL4DLL\Common\SharedToolsLib32.lib"
"kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib"
"advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib"
"odbc32.lib" "odbccp32.lib"
/IMPLIB:"D:\Projets\XL4DLL\Release\XL4DLL32.lib" /DLL /MACHINE:X86
/OPT:REF /SAFESEH /INCREMENTAL:NO /PGD:"D:\Projets\XL4DLL\Release\XL4DLL32.pgd"
/SUBSYSTEM:WINDOWS /MANIFESTUAC:"level='asInvoker' uiAccess='false'"
/ManifestFile:"tmp_Win32_Release\XL4DLL32.dll.intermediate.manifest"
/OPT:ICF /ERRORREPORT:PROMPT /NOLOGO
/LIBPATH:"C:\_tools\boost_1_68_0\stage\lib" /TLBID:1
There is another difference between P1 and P2 projects configuration:
P1 is configured to use "Use MFC in a Shared DLL"
P2 is configured to use "Use Standard Windows Libraries", because it requires the use of Windows.h header and uses symbols not defined with MFC usage.
I have a small test project that I want to build with TeamCity. In TeamCity I have created a build step with runner type 'Visual Studio' solution. The problem is it is not building. The error I get is:
error C1069: cannot read compiler command line
Here a part of the build log:
[16:55:05]ClCompile
[16:55:05]CL
[16:55:05]C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\CL.exe /c /ZI /nologo /W3 /WX- /sdl /Od /Oy- /D WIN32 /D _DEBUG /D _LIB /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fo"Debug\\" /Fd"Debug\vc120.pdb" /Gd /TP /analyze- /errorReport:queue UnitTest.cpp
[16:55:05]UnitTest.cpp
[16:55:05]c:\data\teamcity buildagent\work\d8c46b39964cb4dc\testlibrary\unittest.cpp(27, 0): error C1069: cannot read compiler command line
Try removing the space in the TeamCity build agent path:
c:\data**teamcity buildagent**\work\d8c46b39964cb4dc\testlibrary\unittest.cpp
There is a bug with the VS2013 compiler as documented here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/82304c15-37e2-4761-8928-0c67e074bf47/error-c1069-cannot-read-compiler-command-line-on-visual-studio-2013-rc?forum=vcgeneral
(Note, this is referring to the RC and could now be fixed)
I have an MFC solution with 17 sub-projects. I just recently added another dll project and cannot get the executable to link to the renamed version of the library. In the settings for the dll projects in the solution, debug builds all have a 'D' appended to the output name to signify that it's the debug version. In some cases, we do that by changing the TargetName to $(ProjectName)D, and in other cases a post build event copies it from the build directory to the lib directory and renames it appending the 'D'. For this project, when I compile the dll I get the two files as expected: MultiLangD.lib and MultiLangD.dll. This is the linker command line for the dll project:
/OUT:".\Debug\MultiLangD.dll" /NOLOGO /DLL /MANIFEST
/ManifestFile:".\Debug\MultiLangD.dll.intermediate.manifest" /ALLOWISOLATION
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG
/PDB:"C:\WorkSpaces\WorkSpace_CFFT_II_i18n\CFFT_i18n_MBCS\CFFT\MultiLang\Debug\MultiLangD.pdb"
/PGD:"C:\WorkSpaces\WorkSpace_CFFT_II_i18n\CFFT_i18n_MBCS\CFFT\MultiLang\Debug\MultiLangD.pgd"
/TLBID:1 /DYNAMICBASE /NXCOMPAT /IMPLIB:".\Debug\MultiLangD.lib" /MACHINE:X86
/ERRORREPORT:QUEUE
This is the compiler command line for the dll project:
/ZI /nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_WINDOWS" /D "_DEBUG" /D "_AFXEXT" /D
"_MULTILANGDLL" /D "_CRT_SECURE_NO_WARNINGS" /D "_WINDLL" /D "_MBCS" /D "_AFXDLL" /Gm
/EHsc /RTC1 /MDd /GS /fp:precise /Zc:wchar_t /Zc:forScope /GR- /Yu"StdAfx.h"
/Fp".\Debug\MultiLangD.pch" /Fa".\Debug\" /Fo".\Debug\" /Fd".\Debug\vc100.pdb" /Gd
/analyze- /errorReport:queue
In the executable project I list MultiLangD.lib as an additional dependency to the linker, set "Link Library Dependencies" to no, and "Use Library Dependency Inputs" to yes. The MultiLang dll project is not set as a project dependency to the executable. Nevertheless, in the debug build, I get an error because the linker cannot find MultiLang.lib. This is the linker command line of the executable project:
/OUT:".\Debug\WinGFApp.exe" /INCREMENTAL /NOLOGO /LIBPATH:"..\Lib"
/LIBPATH:"..\Student\lib" /LIBPATH:"C:\Program Files (x86)\Microsoft DirectX SDK (March 2009)\Lib\x86"
"MultiLangD.lib" "datastored.lib" "shlwapi.lib" "ws2_32.lib" "MdxReadd.lib" "winmm.lib"
"dxguid.lib" "dxerr9.lib" "dinput8.lib" "Messagingd.lib" "dtccd.lib" "Version.lib"
"SerialTCIMD.lib" "geosrvdll.lib" "NetworkUIDMD.lib" "amp2.lib" "idmmib.lib"
"vmfr2.lib" "d3dx9.lib" "comsuppwd.lib" "vmf_net_db.lib" "jvmfd.lib"
/NODEFAULTLIB:"libc" /NODEFAULTLIB:"libcd" /NODEFAULTLIB:"libci" /MANIFEST
/ManifestFile:".\Debug\WinGFApp.exe.intermediate.manifest" /ALLOWISOLATION
/MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:".\Debug/CFFTInstrD.pdb"
/SUBSYSTEM:WINDOWS
/PGD:"C:\WorkSpaces\WorkSpace_CFFT_II_i18n\CFFT_i18n_MBCS\CFFT\Instructor\Debug\WinGFApp.pg
d" /TLBID:1 /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:QUEUE
This is the compiler command line:
/I"." /I"..\Instructor\csw" /I"..\Instructor\CFFTInstr" /I"..\Student\common"
/I"..\Student\Messaging" /I"..\Student\geotrans" /I"..\SerialTcim" /I"..\AudioServer"
/I"..\NetworkUIDM\UIDM_Include" /I"..\NetworkUIDM\UIDM_JVMF" /I"..\NetworkUIDM"
/I"..\Instructor\cas" /I"..\Jvmf" /I"..\Instructor\JvmfGui" /I"..\Instructor\JvmfCff"
/I"..\NLOS" /I"C:\Program Files (x86)\Microsoft DirectX SDK (March 2009)\Include" /Zi
/nologo /W3 /WX- /Od /Oy- /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "NO_MSGS" /D
"INSTRUCTOR" /D "_CRT_SECURE_NO_DEPRECATE" /D "_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES"
/D "_CRT_NONSTDC_NO_DEPRECATE" /D "_VC80_UPGRADE=0x0600" /D "_MBCS" /Gm- /EHsc /RTC1
/MTd /GS /fp:precise /Zc:wchar_t /Zc:forScope /Yu"stdafx.h" /Fp".\Debug/WinGFApp.pch"
/Fa".\Debug/" /Fo".\Debug/" /Fd".\Debug/" /FR".\Debug\" /Gd /analyze-/errorReport:queue
When I open the .vcxproj file in np++ and search for MultiLang.lib it only appears as a dependency in the release build, while in the debug build settings MultiLangD.lib is listed. This is the debug settings ItemDefinitionGroup node from the .vcxproj file:
</ItemDefinitionGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<Midl>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<MkTypLibCompatible>true</MkTypLibCompatible>
<SuppressStartupBanner>true</SuppressStartupBanner>
<TargetEnvironment>Win32</TargetEnvironment>
<TypeLibraryName>.\Debug/WinGFApp.tlb</TypeLibraryName>
<HeaderFileName>
</HeaderFileName>
</Midl>
<ClCompile>
<Optimization>Disabled</Optimization>
<AdditionalIncludeDirectories>.;..\Instructor\csw;..\Instructor\CFFTInstr;..\Student\common;..\Student\Messaging;..\Student\geotrans;..\SerialTcim;..\AudioServer;..\NetworkUIDM\UIDM_Include;..\NetworkUIDM\UIDM_JVMF;..\NetworkUIDM;..\Instructor\cas;..\Jvmf;..\Instructor\JvmfGui;..\Instructor\JvmfCff;..\NLOS;C:\Program Files %28x86%29\Microsoft DirectX SDK %28March 2009%29\Include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
<PreprocessorDefinitions>WIN32;_DEBUG;_WINDOWS;NO_MSGS;INSTRUCTOR;_CRT_SECURE_NO_DEPRECATE;_CRT_SECURE_CPP_OVERLOAD_STANDARD_NAMES;_CRT_NONSTDC_NO_DEPRECATE;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<BasicRuntimeChecks>EnableFastChecks</BasicRuntimeChecks>
<RuntimeLibrary>MultiThreadedDebug</RuntimeLibrary>
<PrecompiledHeader>Use</PrecompiledHeader>
<PrecompiledHeaderFile>stdafx.h</PrecompiledHeaderFile>
<PrecompiledHeaderOutputFile>.\Debug/WinGFApp.pch</PrecompiledHeaderOutputFile>
<AssemblerListingLocation>.\Debug/</AssemblerListingLocation>
<ObjectFileName>.\Debug/</ObjectFileName>
<ProgramDataBaseFileName>.\Debug/</ProgramDataBaseFileName>
<BrowseInformation>true</BrowseInformation>
<WarningLevel>Level3</WarningLevel>
<SuppressStartupBanner>true</SuppressStartupBanner>
<DebugInformationFormat>ProgramDatabase</DebugInformationFormat>
</ClCompile>
<ResourceCompile>
<PreprocessorDefinitions>_DEBUG;%(PreprocessorDefinitions)</PreprocessorDefinitions>
<Culture>0x0409</Culture>
</ResourceCompile>
<Link>
<AdditionalDependencies>MultiLangD.lib;datastored.lib;shlwapi.lib;ws2_32.lib;MdxReadd.lib;winmm.lib;dxguid.lib;dxerr9.lib;dinput8.lib;Messagingd.lib;dtccd.lib;Version.lib;SerialTCIMD.lib;geosrvdll.lib;NetworkUIDMD.lib;amp2.lib;idmmib.lib;vmfr2.lib;d3dx9.lib;comsuppwd.lib;vmf_net_db.lib;jvmfd.lib;%(AdditionalDependencies)</AdditionalDependencies>
<SuppressStartupBanner>true</SuppressStartupBanner>
<AdditionalLibraryDirectories>..\Lib;..\Student\lib;C:\Program Files %28x86%29\Microsoft DirectX SDK %28March 2009%29\Lib\x86;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
<IgnoreSpecificDefaultLibraries>libc;libcd;libci;%(IgnoreSpecificDefaultLibraries)</IgnoreSpecificDefaultLibraries>
<GenerateDebugInformation>true</GenerateDebugInformation>
<ProgramDatabaseFile>.\Debug/CFFTInstrD.pdb</ProgramDatabaseFile>
<SubSystem>Windows</SubSystem>
<TargetMachine>MachineX86</TargetMachine>
</Link>
<Bscmake>
<SuppressStartupBanner>true</SuppressStartupBanner>
<OutputFile>Debug/CFFTInstrD.bsc</OutputFile>
</Bscmake>
<PostBuildEvent>
<Message>Copy Executable</Message>
<Command>if not exist ..\exec mkdir ..\exec
copy debug\WinGFApp.exe ..\exec\CFFTInstrD.exe
</Command>
</PostBuildEvent>
<ProjectReference />
<ProjectReference>
<UseLibraryDependencyInputs>true</UseLibraryDependencyInputs>
<LinkLibraryDependencies>false</LinkLibraryDependencies>
</ProjectReference>
</ItemDefinitionGroup>
Unfortunately, all the executables and dlls generated are copied to a single directory as post build events, so I have to follow the "append D" naming convention to avoid overwriting artifacts from other builds. I'm not sure why none of the other dll projects in the build have this problem. I am obviously missing something here but cannot figure out what it is. Can someone please enlighten me on what I'm doing wrong and how to accomplish this. Thanks.
EDIT
I forgot to mention that I have also tried adding a reference to the project in Common Properties->Framework and References.
Also, while the compilation is under way I see Automatically linking with MultiLang.lib scroll by.
Ok, I got it working. I removed the reference and set Linker->General->Ignore Import Library to Yes. I left everything else the same and now it compiles and links just fine.
I'm new to Visual Studio and Windows as a development platform, and I'm having troubles linking a static library from one 'Project' into an executable in another. The library builds without error, but linking bails after finding several STL template instantiations defined in the library.
For the purpose of this question, Project A builds a static library, which I then attempt to link with in Project B.
I'm hoping someone can point out what I'm missing here.
The build command line for Project A:
/Od <includes> /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_WIN32_WINNT=0x0501" /D "DEBUG" /D "WS4_WIN32" /D "AF" /D "_VC80_UPGRADE=0x0710" /D "_MBCS" /Gm /EHsc /RTC1 /MTd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /Wp64 /ZI /TP /wd4290 /errorReport:prompt
The build and link command lines for Project B:
/Od <includes> /D "WIN32" /D "_DEBUG" /D "_CONSOLE" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /MDd /Fo"Debug\\" /Fd"Debug\vc90.pdb" /W3 /nologo /c /ZI /TP /wd4290 /errorReport:prompt
/OUT:<exe name> /INCREMENTAL /NOLOGO /MANIFEST /MANIFESTFILE:"<exe name>.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:<pdb name> /SUBSYSTEM:CONSOLE /DYNAMICBASE /NXCOMPAT /MACHINE:X86 /ERRORREPORT:PROMPT kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib <Project A Lib file>
When the linker runs, I get a ton of errors of the following form:
msvcprtd.lib(MSVCP90D.dll) : error LNK2005: "<some STL template instantiation>" (<mangled name>) already defined in <Project A>.lib(<some Project A object>.obj)
I think this is telling me that an STL instantiation defined in an object of my library is also defined in msvcprtd.lib. What's not clear to me is if I'm not building my static library correctly, or if my linker settings are wrong. I would appreciate any guidance on this.
You have mismatching runtime libraries specified.
It is set to /MTd for project A and /MDd for project B.
/MTd - Multithreaded Debug
/MDd - Multithreaded Debug DLL