Reputation: 195
I am running tcl/tk (8.5) with an external c library to interface to an d2xx USB library. I am running Windows 8 and trying to compile the library using the VS 2012 Native Tools
Command Prompt. When I start the command prompt my PWD is:
\Program Files (x86)\Microsoft Visual Studio 11.0\VC
The c library (tclftd2xx.c) comes with nmake files for virtual studio that properly sets up the environment to link to the required tcl libraries and with the d2xx header.
In the VS command window, I CD to the directory containing the makefile.vc and type:
nmake .....
and I get my tclftd2xx.dll.
tclftd2xx.dll calls msvcr110.dll
. When both of these are properly placed in /Tcl/lib, they work great on my Windows 8 system, and on Vista and Windows 7.
However, when installed on Windows XP, windows cannot load the tclftd2xx.dll.
I did some searches and discovered that I have to configure VS2012 for v110_xp toolset. The link (http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx) has this note:
Visual Studio 2012 solutions and projects which have been switched to the v110_xp toolset can be built from the command line using MSBuild or DEVENV without additional steps.
However, if you wish to use CL and Link directly, additional steps are needed. Note that the steps below may be automated by creating a batch script.
Which I did here:
REM set include and path variables
set INCLUDE=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Include;%INCLUDE%
set PATH=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Bin;%PATH%
REM When targeting X86, set the lib path as follows:
set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib;%LIB%
REM set the compiler options
set CL=/D_USING_V110_SDK71_;%CL%
REM When targeting x64, set the lib path as follows:
REM set LIB=%ProgramFiles(x86)%\Microsoft SDKs\Windows\7.1A\Lib\x64;%LIB%
REM Specify the correct subsystem and subsystem version for the linker based on the type of
REM application you are building. Applications targeting the x86 version of Windows XP must specify
REM subsystem version 5.01, and applications targeting x64 must specify version 5.02.
REM For x86 console applications:
set LINK=/SUBSYSTEM:CONSOLE,5.01 %LINK%
REM For x64 console applications:
REM set LINK=/SUBSYSTEM:CONSOLE,5.02 %LINK%
To build the xp version, from a VS command line I 1) ran the .bat file 2) nmake .....
I get a .dll that is exactly the same size as the windows 8 targeted dll.
So I have two questions:
.bat file
, or does executing the .bat file do the full configuration? Upvotes: 1
Views: 2636
Reputation: 1404
I came up with the following batch script to set the variables. It seems, I will have to include this with my project to let people build my code with visual studio 2012.
@echo off
goto :start
:check_dir
if not exist "%~1" (
echo Directory "%~1" does not exist.
echo Things may not work as expected.
)
goto :eof
:start
setlocal
if "%PROCESSOR_ARCHITECTURE%" == "x86" (
set "ProgramFiles(x86)=%ProgramFiles%"
)
set "BINDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Bin"
set "INCDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Include"
set "LIBDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Lib"
set "SUBSYS=CONSOLE,5.01"
REM for x64 instead of x86:
REM set "LIBDIR=%ProgramFiles(x86)%\Microsoft SDKs\Windows\v7.1A\Lib\x64"
REM set "SUBSYS=CONSOLE,5.02"
call :check_dir "%%BINDIR%%"
call :check_dir "%%INCDIR%%"
call :check_dir "%%LIBDIR%%"
endlocal & (
set "CL=/D_USING_V110_SDK71_;%CL%"
set "LINK=/SUBSYSTEM:%SUBSYS% %LINK%"
set "LIB=%LIBDIR%;%LIB%"
set "PATH=%BINDIR%;%PATH%"
set "INCLUDE=%INCDIR%;%INCLUDE%"
)
Upvotes: 2
Reputation: 33223
You should not have to include both the msvcrt and the tclftd2xx dlls. The compiler generates a manifest that prodvides the necessary information to the runtime loader to state which C++ runtime should be loaded. The error you are seeing is that the rules.vc file needs updating to support the newer compilers. Once this is done the makefile variable _VC_MANIFEST_EMBED_DLL will get set to the command required to merge the compiler manifest file into the resulting DLL.
I've updated the project at github so this should no longer be a problem.
Upvotes: 0