Visual C++ build produces an empty .obj while manual compile succeeds - c++

I have a Visual C++ Professional 2019 Version 16.11.8 solution with 4 projects, one of them a GoogleTest project, others are libraries. It worked long just fine, but today it started complaining about 4 missing methods in a class. Those are in a separate .cpp file.
During build, it compiles this file, but the result is only 70 kB (should be 500kB) with no methods in it (examined with objdump). Unresolved references. When I compile the specific file using Ctrl-F7, then issue the build, everything is OK.
I've tried clean all, rebuild all, restart computer, delete all the Debug directories together with .vs, but nothing.
I haven't customized anything on that ,cpp file, at least not on purpose.
What can I do? Thanks in advance.

The cause was some misplaced header and source files. Header in source directory or the opposite way, I don't remember. Making order healed the project. Apparently I wans't careful enough during adding new files.
Make sure, that
Each header file gets in the project include directory.
Each header file is added via the new header template, and gets .h suffix.
Each source file gets in the project src directory.
Each source file is added via the new cpp file template, and gets .cpp suffix.

Related

QtCreator - Compiling issue - External source files

I have a Qt project, accessing another cross-platform (boost) project on my disc. Adding the header includes does not seem to cause any problem.
#include "../../Visual Studio 2015/Projects/..." //Header file down the road
Adding existing source files to the sources folder in my Qt Project works also without a problem, the files are found and I can open them. I believe the files are not correctly compiled - if at all - as I get a linker error, telling me that %sourcefile%.obj could not be opened. (not created)
LNK1104: cannot open file 'debug\Error.obj'
I tried copying the content of Error.cpp into a new .cpp file created in the Qt project directory. After that the error message jumped to the next source file. I could now do this for all source files, but this seems to be quite... unhandy. Changes in the original project won't affect the Qt project then.
Does somebody know the problem / got a solution to it ?
I checked this question, answer and comments already, but that did not seem to fix the error or change anything.
The solution was quite simple and a little strange. It appears that something is causing an issue when using paths with spaces with Qt's include(...) and SOURCES in a *.pro file.
//This apparently works and source files are compiled.
include(C:/ProjDir/ProjName.pri)
//This works too, but the source files are not being compiled.
include("../../Visual Studio 2015/Projects/ProjDir/ProjName.pri")
Thanks to JKSH on the Qt-Forums and Sebastian for his hint using a .pri file.

Visual Studio C++ able to compile with compile errors (red underlines)

I am having a problem of getting compile errors (red underlines) like:
Error: cannot open source file "stdafx.h"
Here an edited screenshot of the environment:
On the LEFT is my Visual Studio Solution Directory list with the "Show All Files" off.
I am working on a school project, and each Folder are the source files of different parts of the project with different people who are in-charge of them.
For example, Student A and B are incharge of AST and PARSER folders (we will call them sub-projects).
We have an API for each sub-project so other sub-projects know what to call.
At the TOP-CENTER, we have my Source File for a class QueryProcessor. (just the first few lines)
Below it, is the Output for the Build Success.
The red lines are all over all the classes, mainly cause the #include "stdafx.h" cannot be opened by the environment.
On the RIGHT, that is the stdafx.h where we include all the different sub-projects so we save the trouble of each project having a different stdafx.h
However, I am able to build the project. I am pretty sure I am doing this directory/linking wrongly.
This should work
Right click on the solution file
Click Open in Windows Explorer
Find file stdfx.h in explorer and copy the path of the folder
In visual studio solution explorer, Right click on the project file
Click properties-> C/C++ -> General
In the Additional Include Directories paste the path
Combining folders and virtual folders in VC is from my point of view messy because the virtual folders indicate that all files are in one directory and the folders created on the harddrive obviously indicate that all files are in different directories. You can combine it if you know what's going on but in your case I would not recommend it.
I assume you missunderstand the purpose of stdafx.h The purpose of this header file is NOT to put all header filles into it and then just include it to all other files. Here is a SO question about this Purpose of stdafx.h
After cleaning up your stdafx.h file include as many header files into your .cpp files and only put these includes in your header files if they are required in the header file
Turn on show all files, now you will work with actual folders and you can be sure that if you adress a folder like "PKB" that this folder really exists since you can see it in the left solution explorer.
If you use using namespace std; for example make sure you also include the required header files. You might think "hey I already included e.g. iostream in another header file which I now include in this header file so I don't need it" That will really destroy you when you work with bigger projects.
Oh and regarding the stdafx.h include problem as soon as you switch to show all files I assume you will realise that stdafx is in a different file than the file where you use the include. Maybe something like #include "..\stdafx.h" is required (depending on your structure).
I think it's obivious but if you include a header file the include is allway relative to the file which is including the other header file.
stdafx.h is commonly used for creating a precompiled-header, which essentially is a compile-time optimisation such that the compiler will not continually compile these headers for every compilation unit.
If any of these headers changes, you will need to do a full system rebuild.
In reality it is preferable only to use it to include standard headers plus third-party headers (like boost libraries and similar) that you are not ever going to change.
You may decide that some of your own libraries are "set in stone" and can also be included.
Every project, i.e. every part of the project that is built into a separate unit (DLL or .exe) should have its own precompiled header and its own version of stdafx.h
Projects should only ever include their own .stdafx and not those of other projects, therefore this header file can also be used to define your dllexport macro.
When arranging your project headers you should be aware of:
1. Which headers are included externally
2. Which headers are only included internally, and are not even included indirectly externally.
The latter sort should include your stdafx.h file and should ideally not be in the same directory as those headers included from outside your project.

Ignore missing .obj files or "/P switch + external tool + linker = hell"

I am trying to make a setup as described in my previous question: Any way to parse preprocessed source through external tool before it compiles?
All of my .cpp files are set to compile with /p, which generates .i (preprocessed) files for all of them, but no object files. Those generated .i files are also added to my project, and an external build tool option is set to my tool that modifies those files, and saves them under new extension, .obfuscated.cpp
All those .obfuscated.cpp files are also added to the project, and are set to compile normally, producing object files.
Now the problem is that Visual Studio (or the linker, someone of them) for some reason want the obj files both from .cpp files (which now are just saved to .i files, no object files produced), and from .obfuscated.cpp (which are created normally).
I would assume that the linker would not require .obj files from sources that are set to compile with /P option, because, well that option prevents object files from being created.
Now I only see two ways to solve this:
1) Do the build in two steps. In the first one make sure all the .cpp files are preprocessed and saved to .i files. This build does not have to complete, just has to save .i files. Then after that, I select all the .cpp files and set them to "Exclude from build", then everything compiles as it should.
2) Instead of adding the files to the project and using the external build tool option, make a pre-link step instead, in which my own tool would automatically find all the .i files (could take all *.i in a certain directory), process them to *.obfuscated.cpp, and then manually call cl.exe on all of those files to produce object files, rename them to proper names (so that the linker thinks they are object files created from original sources) and put into intermediate directory. But in this case I would have to keep track of all the compiler arguments and change them accordingly if something changes in my project...
Both of these solutions don't seem very beatuful. Is there some other way to do this in Visual Studio? Can't I just tell the linker to ignore missing .obj files? (All the symbols will be found anyway...)
maybe this can help you : instead of the extension .obfuscated.cpp give it an simpler extension like .icpp and add those .icpp files (after first compile) to your project (in a separate folder in your project) ,then for each of those .icpp files goto their property-page and set the correct build-tool (C\C++ compiler) and your .obj files retain the same name-part as your original .cpp files so linking should automatically be done correctly.
I had a similar problem.
I just wanted to see the result of the preprocessing (no extra external tool or so).
I ended with the following solution:
I create an empty object file: just add an empty source "dummy.cpp" to your project.
NOTE: dummy.cpp must be empty, otherwise the Linker will complain about
duplicate symbols.
I mark the "*.icpp" sources as "C++-Compiler" and /P
as mentioned above.
I create a PreLink action, containing a
copy $(IntDir)dummy.obj $(IntDir)xyz.obj
for each "xyz.icpp" source.
if you want both compiled and precompiled output:
add a xyz-wrapper.cpp for each xyz.icpp.
The wrapper should contain only one line like this:
#include "xyz.icpp"
Now the Linker still searches for the xyz-objects, which are still not created, but we give it the empty dummy objects.
NOTE: to get Syntax-Highlighting for the *.icpp files in VisualStudio, you should add this extension at ->Tools->Options->TextEditor->FileExtensions

About stdafx.h missing in my compiler(mingw32 on windows)

I just have a quick question. I've noticed that I don't have stdafx.h in my compiler(mingw32 on windows)
Am I supposed to have it? Or maybe is there a way to get around it?
Thanks for reading
EDIT: ok here is my current build log once I took out ALL of the includes of stdafx.h
http://pastebin.com/bczLr8xY
Read this wikipedia article. The paragraph I linked and the paragraph below it (mingw32 uses GCC).
http://en.wikipedia.org/wiki/Precompiled_header#stdafx.h
Since stdafx.h contains the most common headers I would remove every instance of #include stdafx.h and try to compile. If you get compile errors that a certain function is missing, add the appropriate header. Rinse and repeat.
No. Stdafx.h is created with MSVC++. It usually contains most common headers files. And Stdafx.h is included in every .cpp file in the beginning. It's precompiled header (if you've chosen so in the settings) created by MSVC++.
To all:
Using the pre compiled header file stdafx.h in the visual C++ always creates one or the other problem n case u have created a "Windows Console App" from Visual C++.
The Solution to it is that, just create "Empty Project", rather than the pre-compiled windows console application. After creating the Empty project, create the source File. Write the business logic and add all the required resource and header files. Keep the external dependency files in the same directory in which your source code is: e.g., C:\Users\John\Documents\Visual Studio 2010\Projects\xyz.cpp\xyz.cpp.
Finally add the source file to the global scope, that is add it to the "Empty Project" created already. It can be done by Clicking "File" on Visual Studio prompt and select the option of adding the source file to the project.
Thanks and Regards:
Rouf Khan

Auto-generated C++ file in the Pre-build not included in the compilation

I have a custom parser that generate C++ files and add them into a project. What I would like to do is call this parser before building my project and compile the new generated files in the same build. I use VS2010. I tried to call the parser in the PreBuild, the generated files are correctly added in the project (I can see them in the IDE) but they are not compiled. Like if the project doesn’t know that it have new files in it.
I'm not sure, but do not fully know, if files added to the project during the PreBuild phase are actually included in the compilation. I believe that the files included is calculated before the PreBuild phase is run.
One way to work around this though is to add an empty file into the project and include it in the compilation. Have your prebuild phase overwrite this file and the postbuild phase re-initialize it to nothing. That should fix this issue.
If the generated files are named .cpp they should be compiled. Otherwise you might need to specify that they should be compiled as c++ files, somehow.
If your generated files are created from some other file which you edit, you can set up a custom compile step on the "input" files for your generator. That helps with re-building files.
Autogenerated files aren't auto-added to the project and therefore aren't compiled. You see them in the IDE because they lie in the same folder(s) as your project files.
The only snag with overwriting an existing project file with new, auto-generated contents is that, if you use a source control system, those files will be read-only. Overwriting them during an auto-generation phase might upset your source control process.
You could try this:
MyProject/
MyWrapperFile.cpp <-- official project file
MyWrapperFile.cpp contents
#include "stdafx.h"
#include "_AutoGenFile1.cpp"
#include "_AutoGenFile2.cpp"
// etc.