I have a C++ Visual Studio project which I'm trying to compile for x86 and x64 architecture. I've googled and found a lot information how to do it and it seems to work, but it left me deeply confused about what is going on behind the curtains.
Apperently, the only difference in the settings is a switch in the linker command line flags (to be precise, it's the /MACHINE flag).
If that's the case however, then the object files of the compilation must be platform independent - which is somehow the exact opposite of what I always assumed it to be, since object files are supposed to be sequences of machine code which in turn should be platform dependent.
So, my question is: which part(s) of the build process does not behave the way I thought it would?
Thanks for your time and wisdom!
Michael
When compiling for 32-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\cl.exe. When compiling for 64-bit x86, Visual Studio uses the compiler \Program Files\Microsoft Visual Studio 10.0\VC\bin\amd64\cl.exe. The first compiler produces 32-bit object files, the second produces 64-bit object files. This can be seen by running dumpbin.exe on the object files to see their specified architecture.
The compiler invocation remains the same (more or less) -- what changes is the executable $PATH that is set before building. By pointing the PATH to the 32-bit or 64-bit directory, it sneakily changes the whole set of programs that is run to build your project. You can see this by looking at the Project Properties > Configuration Properties > VC++ Directories > Executable Directories, and clicking on "Edit". In the "Inherited Values" box you'll see the path for the current Configuration and Platform.
Related
I'm having trouble in running a program with CGAL and Boost library on Visual Studio 16. It shows a message saying the 'ALL_BUILD' path is not available, hence it is unable to start the program. What should I do?
ALL_BUILD is a convenience target that builds all targets. It is not an executable. Select another target in the solution, like a test or an example, to run.
I've installed both FreePascal compiler and OmniPascal extension for VisualStudio code, but code completion doesn't work. In the manual you are saying that I need to write the path to Delphi compiler int the user settings, but nothing is said about FPC.
Set the omnipascal.freePascalSourcePath setting to the folder that contains the FreePascal sources
Set the omnipascal.defaultDevelopmentEnvironment setting to FreePascal
Restart Visual Studio Code.
Example:
"omnipascal.freePascalSourcePath": "C:\\lazarus\\fpc"
"omnipascal.defaultDevelopmentEnvironment": "FreePascal"
This will instruct the OmniPascal language server to lookup Pascal units (.pas and .pp files) in that directory and all its subtrees recursively.
I'm porting a 32-bit C++ app to 64-bit (using VS2008).
I'm not sure what does this field mean in the VS2008 ::
Visual studio ->Configuration Properties-> Linker-> Advanced Options->Target Machine.
By default it's value is set to "Not set".
Is it compulsory to change it's value to "MACHINEx64" if I want my application to be ported to 64-bit executable.
Yes, this is a very important option. It sets the IMAGE_FILE_HEADER.Machine field in the executable file. The very first field of the EXE or DLL header.
Windows check this when it loads an EXE and knows whether it needs to create a 32-bit or a 64-bit process from that field. The only reason it is a the Linker + Advanced property page is because you don't normally change it. The setting is pre-selected by the project configuration you created. If you get "Not Set" then you are basically doing it wrong, hard to guess what you are doing.
Assuming you have a properly configured project that builds a working 32-bit build for your program, you create the 64-bit build with Build + Configuration Manager. In the "Active solution platform" combobox at the upper right, select <New...>. Pick "x64" in the dialog. Hopefully the other defaults (Copy settings from = Win32, Create new project platforms ticked) are correct for yours. Go back to the Linker + Advanced property page and the setting should have changed to MachineX64.
This option relates to the linker option /MACHINE and is a hint for the linker for what target architecture to link the object code if he (the linker) cannot determine this from the object file. As MSDN states you usually have not to specify this. So no you don't need to explicitly specify this flag when porting your code.
I am writing a simple C++ application using the Visual Studio IDE and the VC++ compiler.
In this application I have an erroneous file that affects the other files as well. When I compile it, as expected I get errors. Now, if I remove all references to the file from my project, and then run it, the compiler will still exit in an error. In the compile message I then see the filename of the erroneous file. The only way to prevent this from occurring is by either removing all contents of that file, or remove the file, and then recompile it.
My guess is, because VC++ is 'smart' it saves compilations and when they are unaffected it doesn't recompile it. But because the erroneous file affects the other files, some compile errors (not all) simply stay.
Does anyone know how to disable such behaviour?
Can you show the errors ?
If the file contains actual functional code then fix the compilation errors ?
If the file does not contain functional code, then what is it doing in your project.
I expect this "erronous" file to be a header (.h) file that is included in other c++ files, so when it tries to compile the c++ files it will generate an error (or more) per c++ file.
If you just remove the file from the IDE project; the compiler will still include the file (because it still exists on disk); and will continue generating errors.
If you actually remove the file on disk, then you will have other types of errors.
In all cases, just fix the compilation errors.
To recompile all files you can rebuild all, or make a clean build.
Yes VC++ will save compilations if things have not changed, it will probably say up to date.
I don't think that you can disable it, but a clean build should be able to solve it. If that is the entire problem, also check how it is linking things, there you should be able to remove references to files.
The build should be under the build tab.
MSBuild and the Visual C++ compiler to an excellent job producing a correct binary when you make changes such as adding or removing a file. Chances are, even without a complete rebuild the compiled executable will be correct. If you are seeing unexpected behavior, it is most likely caused by one of the following things:
Check that Visual Studio is configured to build your project before running it. Check the following options under Tools → Options... → Projects and Solutions → Build and Run:
Before building: Save all changes
On run, when projects are out of date: "Prompt to build" or "Always build"
On run, when build or deployment errors occur: "Prompt to launch" or "Always launch"
If Visual Studio asks if you want to run an old version of your program, you may have introduced a compile error by removing the file, so the compiled binary will certainly be out-of-date until you correct it.
If your project contains a file that directly or indirectly #include "yourRemovedFile", then removing the file from the project may have no effect.
The Visual Studio Errors List reports issues independently from the compiler. You might be seeing old errors reported that are no longer relevant to your project but have not been cleared from the UI yet. In these cases, when you run your program you would still get the same results. You can also see if this is your problem by restarting Visual Studio and seeing if the error messages persist.
When I compile my code in visual studio c++ 2008 I get the following error:
fatal error LNK1104: cannot open file 'C:\Users\...\Documents\Visual Studio
2008\Projects\...\Debug\....exe
I just copied my code from another project in visual studio C++ and pasted it in this project again in VS C++. Can it cause this error?
This can happen because, for example, the executable is currently executing or opened by another program, or because you don't have the right permissions for that directory.
open TASK MANAGER and see if the process of the .exe is running in background even after closing it. if yes, then kill the process and then try to run it again.
This can happen if you have turned on preprocessor output, e.g. in Properties | C/C++ | Preprocessor | Preprocess to a File == YES. Creating a preprocessor output file (of file type .i) is mutually exclusive to creating an object file (of time .obj).
In my case it was caused by the "Incremental Linking" option of the projects (Visual Studio 2015). Maybe because the files were also dependencies of other projects from the same solution, not sure...
I had the same problem (I don't say that this is exactly your case, but still) and it was quite strange because when I changed the code a bit everything worked normally... And I just found out that my antivirus blocked the .exe file as a possible threat (idk, mb it didn't like how I worked with memory by my C++ program). So, the source of LNK1104 can also be the antivirus.