I'm taking a 32-bit source library and compiling on a 64-bit platform and getting alignment issues (not only 32-bit vs 64-bit but also character set as well).
I want to place all the 64 bit configurations into a "Win64" folder and the 32-bit configurations into a "Win32" directory.
I'm looking into some guidance for modifying the project file so that the target library and dll filenames will be in terms of the configuration.
Examples:
Win64/testrunner_x64d.lib -- Library, debug, 64-bit platform, ASCII
character set.
Win64/testrunner_x64ud.lib -- Library, debug, 64-bit platform,
Unicode character set.
Win32/testrunner_x32d.lib -- Library, debug, 32-bit platform, ASCII
character set.
Win32/testrunner_x32ud.lib -- Library, debug, 32-bit platform,
Unicode character set.
I'm new to using configurations in Visual Studio 2010 and also porting an existing project.
For the character setting, go to "Configuration Properties"->"General"->"Project Defaults"->"Character Set", chose the one as you wish.
For the lib's name for different configuration, you can set it via "Linker"->"General"->"Output File"
Related
I have successfully build PCL for 64 bit windows using CMake and Visual Studio 2013. I have build all dependencies by my own (boost, Flann, QHull and VTK). Now I need to create a 32 bit version. Unfortunately CMake has problems to reference the VTK libraries. For 64 bits it adds the full path to the visual studio project files e.g. "D:\path\to\vtk\64\vtk-6.1.lib". But for 32 bits it only adds "vtk.lib". Even the version number is missing which is always part of the filename. The compiler has no chance to find it. It would be very cumbersome to patch all the PCL projects by my own.
I have already compared the CMakeCache.txt files for 32 and 64 bit. Except the 32/64 bit differences they are equal.
Has anybody an idea what I have might done wrong?
The PCL CMake script loads the VTK using the find_package(VTK) command. The path to the package is specified by the VTK_DIR variable. This variable points to the folder where the VTKConfig.cmake is. For x64 and x86 you will have different folders. For some reason the x86 version of the VTKTargets.cmake file which belongs to the VTKConfig.cmake was empty. After copy and paste the content from its x64 counterpart and some search and replace I was able to compile the project.
So the root cause was that the VTKTargets.cmake was empty. But I do not know why it was empty. I had build the VTK in x64 and x86 mode.
I am looking for a way to program for MIPS assembly using VS2013 - but there is no assembly type project.
Is there a way to do this and get the .s output files of MIPS so I can later run them on other machines, and if I can't do this on VS2013 than how do I program MIPS on Windows 7?
Thanks
The assembler used in visual studio is Microsoft assembler (MASM), and yes you can program assembly language on it.
select an "Empty Project" then configure the "Build Customizations" of the project to use MASM, after that add a new c++ source file and rename it to any name .asm
Here are the detailed steps:
http://kipirvine.com/asm/gettingStartedVS2013/index.htm
And as for assembling your code to run on MIPS, I guess you can't do that with MASM, because it's a x86 assembler,
here is a list of the supported processor types directives on masm
.386
.386P
.387
.486
.486P
.586
.586P
.686
.686P
.K3D
.MMX
.XMM
Refer to
https://msdn.microsoft.com/en-us/library/vstudio/8t163bt0%28v=vs.100%29.aspx
the processor section.
Nevertheless, there is an option in the project "Properties" > "Linker" > "advanced" that let you chose between different machines, including Mips, but I guess this will merely set the Machine Flag in the PE header to MIPS and when the assembler try to build your module it will find a conflict between the machine type flag and the code in the module. But I'm not sure If you can build codes for MIPS.
To run MIPS programs on Windows 7, you need some type of emulator and a corresponding tool set. In the case of ARM processors, there are emulators that include a source level debugger and tool sets, including compilers, assemblers, linkers, and binary image output utilities for embedded systems. There's also a debugger for embedded systems that is run from Windows and some type of connection to the embedded system. The tool set runs on Windows, but targets the emulator or an actual embedded system. I don't know if there's a equivalent tool set and emulator like this for the MIPS processor.
I use Visual Stodio 2013, Ultimate.
In VS C++ Directories -> Include Directories I defined all directories where it should find headers for architecture and mode I chose. When I build project with that architecture and mode - it compiles fine.
But interpreter doesn't see headers. All my includes in IDE windows has red line under, and message "can't find header ...". And interpreter don't helps me with namespaces, for example.
How to set my project help me coding? Now coding is like I do it in Notepad. I even deleted x32 default configuration.
PS: before that I had problem with x32/x64. I wanted x64, and set it in window above code. But in Project Configuration it still tried to work with x32. I changed Solution settings for that. It still turns back x32 after I comitted x64. After some fights, I set x64 everywhere, and it started to compile. But now interpreter don't see headers. I wonder where should I set him take settings from x64 platform to work.
Should we change the preprocessor definition from WIN32 to WIN64 while migrating Visual 2012 C++ Projects to Target 64-Bit Platforms.
Now I have built the project with below settigns
MACHINE (Specify Target Platform) is set to /MACHINE:X64.
Target Environment is set to /env x64
in C/C++ project settings -> Code Generation, Struct Member
Allignment to 8 BYtes
Please guide me what else project settings i should target to change.
It's important to note that only the underscore versions of these preprocessor definitions are relevant to the distinction between 32-bit vs. 64-bit machines.
The underscore versions, _WIN32 and _WIN64 are built-ins that relate to the actual physical CPU of the computer that VC++ is running on. On a 32-bit machine, _WIN32 will always be defined (user does not need to define it), but _WIN64 will not be defined. On a 64-bit machine, _WIN64 will always defined and also _WIN32 may be defined but code can rely on _WIN64 to determine if machine is 64 bit.
For Visual Studio 2019 (perhaps other VS versions also):
The non-underscore WIN32 is not well documented and appears to have no bearing on 32 vs 64 machine type. Standard Visual C++ projects for Windows generally don't appear to use it (it may not be in use at all). Thank you to BTJ for making that point.
Another side note for Visual Studio: If you run Visual Studio on a 64-bit machine and select the Win32 vs x64 build configurations, you will notice that WIN32 is defined for the Win32 build configuration but it is not defined for an x64 build configuration. This does not affect the object/binary machine target e.g. 32 vs 64. It's purpose is unclear. It may be for convenience if one wishes to use it to #ifdef certain parts of the source code that are to be compiled differently for X86 vs X64, but again, it has no bearing on the architecture that the compiler targets. For the compiler, the target architecture is determined by the toolset that is selected based on the project target selected "Platform". The linker also has /MACHINE arg e.g. /MACHINE:X86.
Did you mean _WIN32 and _WIN64 macros? If you specified all parameters right (see P.S.) then you don't need change your code. In 64-bit solution must be defined _WIN32 and _WIN64 both. _WIN32 macro specifies that you can use Win32 API and _WIN64 macro specifies that compilation for 64-bit mode. Also you can use different macro for Itanium (_M_IA64) and x86-64 (_M_AMD64). See details in MSDN.
P.S. Did you choose platform parameters manually? You can specify it via VS:
Build Menu -> Configuration Manager.
Select New in Active Solution Platform.
Type or select new platform -> x64 and click OK.
Now in "Platform" row you can simple choose x64.
In VS2015 at least, linker/All Options/Target Machine
this assumes that you're not using a 3rd-party tool (say widget support or hardware driver) that is configured to use x86 code or is built 32-bit while you're trying to build x64, or vice-versa
I created a new c++ project in VS2010. I added x64 as a new solution platform. I tried setting "copy settings from" to both "Win32" and "empty", but neither worked. _AMD64_ is not defined when I select x64 as the platform. Shouldn't it be? Is there another step I am unaware of for compiling for 64 bit?
In anticipation to questions: I am using VS2010 Ultimate, Windows 7 64bit, x64 compilers were selected during VS installation.
You've got all the steps right. An _AMD64_ symbol is not predefined by default by Visual Studio. You'll need to define it yourself if you want to use it:
#if defined _M_X64 || defined _M_AMD64
#define _AMD64_
#endif
But you're not making up the memory of its existence. The Windows DDK comes with makefiles that define this symbol, in addition to some others. Check in makefile.def. The possibilities are:
_X86_
Variously known as x86, i386, and IA-32
(this is the same as VS's predefined _M_IX86)
_AMD64_
Variously known as AMD64, x64, x86-64, IA-32e, and Intel 64
(this is the same as VS's predefined _M_X64 and _M_AMD64)
_IA64_
Intel Itanium (IA-64)
(this is the same as VS's predefined _M_IA64)
…and some others for architectures nobody targets anymore
Ideally, you would configure your build system to predefine a set of known macros that you will then use in your own code. If you don't have a build system, at least set something up in a precompiled header file. That way, you're not relying on implementation-dependent symbols everywhere, and switching compilers is not a colossal chore—the target architecture symbols predefined by GCC are very different from MSVC, for example.