How to compile 64Bit DLL in Eclipse CDT (using Windows SDK)? - c++

What I want to be done: Create a 64bit DLL on win7 that interacts with the Windows API including the OLE32.dll.
What I have got:
I am currently stuck. I download Visual Studio 2015 Community Edition. I tried to create a DLL there and on creation it generated everything but no dll. The program did not complain, everything was setup as in the tutorial but no dll file.
So I skipped this and downloaded Eclipse CDT. I set up using the Visual C toolchain and after minor issues I had my DLL generated. So I used Java to fire it up but it complained (I use JNA for integration) and it seams that I have a 32bit DLL.
So I searched the web and read and did stuff but I am totally lost. Since the Visual Studio 2010 Express edition came without a 64bit compiler I am not even sure if the Community edition of Visual Studio supports 64bit dlls this time.
I also have the Windows SDK v7.1 installed. I link to a library file ole32.dll. It contains the method CoCreateInstance which I require. I have to add this manually in order for the compiler to pick it up. If I switch to the 64bit dll version the compiler complains about the CoCreateInstance method can not be linked.
So basically I am lost here. A source on the web gave a work around for the 2010 Express being not able to create x64 DLL and it turned out that the hint was getting windows SDK since it it comes along with a compiler.
Also I noticed that CDT uses Visual Studio 10 files so I guess it is using this compiler.
I set to both compiler and linker the /machine:64 option. But the linker still complains that the obj file from the compiler is 32bit.
Any Ideas?
[Update]
The Compiler prints the following line so basically it is not able to compile 64bit version. Any idea how to replace it? As said it uses the Visual Studio 10 folder but I also have a Visual Studio 12 and 14 folder as well.
cl : Command line warning D9002 : ignoring unknown option '/machine:x64'

Well, I don't think '/machine:x64' is a cl option but it's one of linker option.
If you want to make some dll maybe with windows sdk or visual studio environment.
I am not sure that my solution is fit for yours or not, this is what i did for my 64-bit project to compile with eclipse and windows sdk 7.1.
I have two eclipse IDEs which are 32bit and 64bit neon version.
I choose a 64-bit one. You can check one of my answer about installation here. In my opinion, any version of them will be fine. It is your choice.
First step. run 'Windows SDK 7.1 Command Prompt from the start menu.
then, start my eclipse on the command window after changing 64-bit development level with command as follows.
Second Step. Setting up path variables to my project.
I have my own project with a properties window.
The important variable seems to be both LIB and PATH variable in my point.
I crosschecked this two variable, one was from the windows SDK's prompt window and another was current setting variables after installation.
SDK variables here
My final variables are
LIB:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Lib\amd64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib\X64
PATH:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319;
C:\Windows\Microsoft.NET\Framework\v4.0.30319;
C:\Windows\Microsoft.NET\Framework64\v3.5;
C:\Windows\Microsoft.NET\Framework\v3.5;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\amd64;
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\Bin\VCPackages;;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\NETFX 4.0 Tools\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\x64;
C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin;;
C:\Windows\system32;C:\Windows;
C:\Windows\System32\Wbem;
C:\Windows\System32\WindowsPowerShell\v1.0\;
Third, I modified my linker flag as you see the picture below.
Finally, I compiled my project successfully.
Here is my build log.
Info: Internal Builder is used for build
cl /c /EHs /MD /Zi /nologo /Foutil.obj "..\util.c"
rc /Fo proc_view.res "..\proc_view.rc"
Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385
Copyright (C) Microsoft Corporation. All rights reserved.
cl /c /EHs /MD /Zi /nologo /Foprocss.obj "..\procss.c"
link /machine:x64 /debug /nologo /OUT:Systemer.exe FreeList.obj LinkedList.obj proc_main.obj proc_view.res procss.obj util.obj Kernel32.lib Psapi.lib User32.lib
The last one had done with checking if my executable file was 64-bit or 32-bit with a dumpbin command.
That is all.
I think the Eclipse with MinGW or cygwin might be a better option.
I hope this is right for you.

Related

Change Platform Toolset when compiling from CMD

I would like to compile a C++ program via Visual Studio command line tools. I would like to target the executable for 32 bit Windows XP. Tried compiling it the usual way, using x86 Native Tools Command Prompt for VS 2019, but it doesn't work on Windows XP, though runs fine on my Windows 10 machine.
Steps I take:
Open x86 Native Tools Command Prompt for VS 2019.
cd to the project directory. There I'll have 2 folders sources and headers, which shall contain .cpp and .h files respectively.
Execute command cl sources\*.cpp /EHsc /D_WIN32_WINNT=0x050103 /I headers /I <path to boost> /link /libpath <path to boost>\boost_1_77_0\bin\x86\lib\libboost_program_options-vc142-mt-s-x32-1_77.lib /out:exec_xp.exe (the project uses the boost library).
Tried this, but it doesn't work. /D \"_USING_V110_SDK71_\" seems to do nothing, and the /SUBSYSTEM:WINDOWS,5.01 piece isn't recognized by the compiler.
I have learnt from this Microsoft page that we should install deprecated Toolset to compile for WinXP. I went ahead to Visual Studio Installer and installed the C++ Windows XP Support for VS 2017 (v141) tools [Deprecated], as said in the tutorial.
But what now? How can I use this Toolset? I can't find it anywhere on my computer, let alone use it! Visual Studio Installer says it's located under C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools, but it's too vague.
UPD:
Tried with msbuild /p:PlatformToolset=v141_xp, getting this error:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(439,
5): error MSB8020: The build tools for v141_xp (Platform Toolset = 'v141_xp') cannot be found. To build using the v141_
xp build tools, please install v141_xp build tools. Alternatively, you may upgrade to the current Visual Studio tools
by selecting the Project menu or right-click the solution, and then selecting "Retarget solution"
Which suggests, the compiler doesn't see the v141_xp toolset. I wonder why? It's installed for sure, I did it via the Visual Studio Installer.
I suggest you could try to set the PlatformToolset property:
msbuild myProject.vcxproj /p:PlatformToolset=…
For more details, I suggest you could refer to the Doc:MSBuild command-line reference

Choose a certain version of Visual Studio's command line toolkit and compile files against a certain version of a C++ run-time environment

I'm using Visual Studio 2017. Trying to compile a package using certain version of the C++ toolkit and to compile against a certain version a c++ run-time environment.
In my case that would mean the latest toolkit against the latest c++ run-time environment libraries.
How do I make this happen? I tried to use /std:c++17 or /std:latest but this results in a build compiled against vc140.dll.
The documentation of neither cl.exe nor link.exe gives any kind of a hint.
Any ideas? Thanks.
In the project properties UI you can set platform Toolset on the "General" page.
For v140 the resulting command lines start:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe
but for v141 they start:-
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\bin\HostX86\x86\CL.exe
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.12.25827\bin\HostX86\x86\link.exe
You can read the command line for yourself if you set the build output to diagnostic (via Tools->Options->Build and Run).
You can set them here using the dropdown
(project properties)
(configuration properties)
(general)
(platform toolset)

cl.exe not found in Visual Studio 2017 [duplicate]

I'm trying to compile a cuda test program on Windows 7 via Command Prompt,
I'm this command:
nvcc test.cu
But all I get is this error:
nvcc fatal : Cannot find compiler 'cl.exe' in PATH
What may be causing this error?
You will need to add the folder containing the "cl.exe" file to your path environment variable. For example:
C:\Program Files\Microsoft Visual Studio 10.0\VC\bin
Edit: Ok, go to My Computer -> Properties -> Advanced System Settings -> Environment Variables. Here look for "PATH" in the list, and add the path above (or whatever is the location of your cl.exe).
For new Visual Studio cl.exe is present in path => C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.23.28105\bin\Hostx64\x64
x64 is for 64bit
x86 is for 32bit
Solve this problem by adding this options to nvcc
nvcc x.cu ... -ccbin "D:\Program Files\Microsoft Visual Studio 11.0\VC\bin"
for example my compiler is VS2012. and cl.exe is in this dir
cl.exe is Microsoft's C/C++ compiler. So the problem is that you don't have that installed where the command line can find it.
nvcc is only a front end for the CUDA specific part of the program. It must invoke a full compiler to finish the job. In this case it cannot find the Visual Studio compiler 'cl.exe'
Check paths, nvcc documentation etc.
I see that this is an old question but I recently got this error on my Visual Studio 2012 when I tried to build my CUDA project. Apparently I had changed my CUDA project to the Nov 2012 pack, changing it back to the v110 that it usually is by default fixed this error.
In Visual Studio, left click on the CUDA project, ->properties->Configuration Properties-> General -> Platform toolset, and choose: Visual Studio 2012 (v110).
I could probably get it to work with the Nov 2012 pack, but the CUDA code does not use any of the additional functions of that pack, so it is not necessary. (That pack contains the variadic templates for C++11.)
Solve this problem by adding the path to environment variables, which can vary slightly depending in the version of visual studio installed in your system, and are you using 32bit or 64bit system
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.34.31933\bin\Hostx64\x64

How to make Visual Studio use the native amd64 toolchain

How can I get Visual Studio 2012 to use the native amd64 toolchain, rather than the default x86_amd64 cross-compiler?
I am building a large library that causes the linker to run out of memory when doing whole program optimization and link-time code generation.
I found two older posts (here and here) asking this same question, but no answers yet. Microsoft provides documentation on how to specify the toolchain on the command line, but not in the IDE.
There is another method of forcing use of the 64-bit linker on a per-project basis for Visual Studio 2013. Edit your .vcxproj file and insert the following after the <Import...Microsoft.Cpp.Defaults line:
<Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />
<PropertyGroup>
<PreferredToolArchitecture>x64</PreferredToolArchitecture>
</PropertyGroup>
You need to set the environment variable "_IsNativeEnvironment" to "true" prior to starting Visual Studio 2012 IDE:
set _IsNativeEnvironment=true
start "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe" your_solution.sln
For Visual Studio 2013, the name of the environment variable is different:
set PreferredToolArchitecture=x64
sbm start "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe" your_solution.sln
Beware that this technique does not work if the version of the IDE does not match the version of the toolchain. That is, if you use VS2013 IDE configured to run VS2012 compiler, you are out of luck. But such combination is uncommon.
Here are some links for further information:
difference between VS12 and VS13
how to embed PreferredToolArchitecture into the project in VS13
If your goal is to use the native environment rather than specifically amd64_x86, you can set the UseNativeEnvironment property in your project file:
<PropertyGroup>
<UseNativeEnvironment>true</UseNativeEnvironment>
</PropertyGroup>
(I have successfully added it to the "Globals" PropertyGroup.)
You can check which toolchain is being used by adding the /Bv compiler option. Example output is below. Notice that the toolchain directory appears after bin\ (amd64_x86 in this case).
2>ClCompile:
2> Compiler Passes:
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\CL.exe: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c1xx.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\c2.dll: Version 18.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\link.exe: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\mspdb120.dll: Version 12.00.31101.0
2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64_x86\1033\clui.dll: Version 18.00.31101.0
I know this is a rather old post, but it's still relevant for VS 2017. Here you also have the "PreferredToolArchitecture" environment variable and a "build in" setting in the IDE is not readily available.
However you can integrate that easily on a project by project base so that you can always chose what tool architecture to use. Maybe this is helpful for some. Do this:
Go to Property Manager and create a new property sheet, e. g. named "x64 Toolchain.props" so you know what it does. With a separate property sheet you can then switch the tool architecture as appropriate by including or not including the sheet into a project.
Open the properties of that new sheet, navigate to "Common Properties\User Macros" and click "Add Macro".
In the dialog you set the name to "PreferredToolArchitecture", the value to "x64" and enable the checkbox "Set this macro as an environment variable in the build environment".
Optionally navigate to "Common Properties\C/C++\Command Line" and add "/Bv" under "Additional Options". This will make the compiler output the tools it uses including its path and version number, might be helpful for checking if really the desired architecture is being used. It will place entries in the log output window like so:
Compiler Passes:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\CL.exe: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c1xx.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\c2.dll: Version 19.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\link.exe: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\mspdb140.dll: Version 14.15.26730.0
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.15.26726\bin\HostX86\x64\1033\clui.dll: Version 19.15.26730.0
Now for all projects that should be build with the x64 tool architecture include the new property sheet into the project in property manager. And for those that should not simply don't include it. That's it.
HTH
Edit:
It seems unfortunately this is not reliable! See below comments. I would really appreciate if MS would wire this setting to some GUI element and make it work consinstently...
I have a similar problem using Visual Studio 2010 on XP 64 SP2. If I set the VC++ executable directory to the amd64 bin (the native x64 folder) as the first in the search path, then I received the TRK0002 error … Invalid handle value.
But if I set _IsNativeEnvironment=true in a Visual Studio 2010 command prompt and start the ide from the command line as posted before, then the error goes away. Apparently, the 32-bit GUI IDE Environment is receiving info from a 64 bit process and is expecting info from a 32-bit process such as x86\cl.exe or x86_64\cl.exe.
In a scenario where you want to compile an IA64 bit executable, and you use the x86_ia64\cl.exe compiler. Since you are using a 32-bit cross compiler and have the _IsNativeEnvironment variable set to true, this must upset the IDE when posting messages in it's window consoles. Set the _IsNativeEnvironment=false, if you have previously set it to true.
The IDE should pick up that a native compiler was being used on a native 64-bit
machine and should have automatically set this variable to the appropriate value when the native compiler was selected from the IDE. A simple fix has never been applied to patch this problem. Solution. Do it yourself from the prompt, or buy the latest IDE from Microsoft to fix the problem.
So, the real wizards at Microsoft are the developers who work mainly from the command line. And the other developers, who wear the pointy hats and sit in the corner, must have been hired from Apple and were more concerned about appearance than function.
The whole purpose of an IDE is to make coding simple, not more complicated than using a text editor and a Makefile from the command line.

VC++ Building directshow baseclasses

I am a newbie to DirectX SDK, Platfrom SDK and DirectShow. I downloaded latest Platform SDK and DirectX SDK August'09. I tried to build sample project in folder:
Microsoft Platform SDK\Samples\Multimedia\DirectShow\Capture\PlayCap\
And had following building errors:
LINK : fatal error LNK1181: cannot open input file 'D:\Program Files\
Microsoft Platform SDK\samples\multimedia\directshow\baseclasses\
WIN2000_DEBUG\strmbasd.lib'
As far, as I understand, I need to build all sources in "Microsoft Platform SDK\Samples\Multimedia\DirectShow\BaseClasses\" directory to get necessary lib.
I tried nmake in that dir and got following:
D:\Program Files\Microsoft Platform SDK\Samples\Multimedia\DirectShow\
BaseClasses\ctlutil.h(278) : error C4430: missing type specifier - int
assumed. Note: C++ does not support default-int.
Here is code on that lines:
278: STDMETHODIMP
279: CMediaEvent::NonDelegatingQueryInterface(REFIID riid, void **ppv)
What I do wrong? Just can't believe, that using Microsoft's libraries must be so hard.
Microsoft has renamed Platfrom SDK to Windows SDK. The lastest Windows SDK is Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1.
Windows SDK for Windows 7 has Visual Studio 2008 2005 project files for all DirectShow projects.
On my Xp64 box, I managed to get the DirectShow baseclasses libs built in order to run the amcap sample. I have the June 2010 Microsoft DirectX SDK installed as well as the Microsoft Windows SDK for Windows 7 (7.1) with all the C/C++ compilers.
First, we have to compile the DirectShow baseclasses :
open a regular old cmd.exe
cd C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
If you're getting an error about not have VCBuild.exe installed, it's because the
sln and various project files (eg: C/C++ vcproj) are ancient, the next command will
upgrade them nicely, changing old stanky vcproj files into new crappy vcxproj files
VCUpgrade is here on my machine :
C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\vcupgrade.exe
Note that even after trying the various combinations of params to vcupgrade,
building the sln with msbuild is a no-go (docs be danged), so I had to directly
compile the project I left the batch file var named SLN anyway because I'm a real revolutionary
VCUpgrade -nologo -overwrite baseclasses.vcproj
This makes it a touch easier to compile different configurations
set SLN="baseclasses.vcxproj"
Note that the baseclasses Release build makes strmbase.lib
and Debug makes strmbasd.lib
amcap needs the Release build tho amcap's build can be debug
A) Compile Release Win32 (== x86)
Using the MsSdk's SetEnv.Cmd lets you avoid all that vsvars32.bat quagmire as well
as the 8 million different cmd shells that have been specially designed to be one
or two fatal flaws away from actually working while relying upon an eplipsy-inducing web of
batch files to do they thing (hey! maybe the two are related!?)
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /release /x86 /xp
I've not had any luck using the 64-bit version of MSBuild (maybe targets?),
but x86 MSBuild has been working no problem
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Release /p:Platform=Win32
B) Compile Release X64
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /release /x64 /2003
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Release /p:Platform=X64
Second, we can now compile both versions of amcap
open a regular old cmd.exe
cd C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\capture\amcap
VCUpgrade the vcproj to a vcxproj
VCUpgrade -nologo -overwrite amcap.vcproj
set SLN="amcap.vcxproj"
A) Compile Debug Win32 (== x86)
Set compiler,lib,include,... paths and then compile
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /debug /x86 /xp
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Debug /p:Platform=Win32
B) Compile Debug X64
"C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\SetEnv.Cmd" /debug /x64 /2003
"C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" %SLN% /p:Configuration=Debug /p:Platform=X64
I used SysInternals *Process Explorer* to verify that each exe was actually 32-bit and 64-bit respectively. It seems inexplicable that most developers I've worked with don't even know about Process Explorer -- I'm in that thing all day. And yes, that is what she said.
For me this error meant "open C:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses\baseclasses.sln" (in my case, in visual studio express 2010) it asks to convert it, do so, then build both "release" and "debug."
Then in your own project, under project settings for your project
example: add
G:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses
to beginning of “VC++ directories” include path, and G:\Program Files\Microsoft SDKs\Windows\v7.1\Samples\multimedia\directshow\baseclasses\debug to your lib path (anywhere in that).
See also https://msdn.microsoft.com/en-us/library/windows/desktop/dd407279(v=vs.85).aspx