I'm compiling own project. And it halted by this error:
LINK||fatal error LNK1181: cannot open
input file
'obj\win\release\src\lua\bindings.o'|
Compiling using Code::Blocks with VS 2005/2008 compiler under win7.
There are also lot of another empty directories where *.o files are missing.
What do they do?
A file ending in .o is an object file. The compiler creates an object file for each source file, before linking them together, into the final executable.
You've gotten some answers, and most of them are correct, but miss what (I think) is probably the point here.
My guess is that you have a makefile you're trying to use to create an executable. In case you're not familiar with them, makefiles list dependencies between files. For a really simple case, it might have something like:
myprogram.exe: myprogram.o
$(CC) -o myprogram.exe myprogram.o
myprogram.o: myprogram.cpp
$(CC) -c myprogram.cpp
The first line says that myprogram.exe depends on myprogram.o. The second line tells how to create myprogram.exe from myprogram.o. The third and fourth lines say myprogram.o depends on myprogram.cpp, and how to create myprogram.o from myprogram.cpp` respectively.
My guess is that in your case, you have a makefile like the one above that was created for gcc. The problem you're running into is that you're using it with MS VC instead of gcc. As it happens, MS VC uses ".obj" as the extension for its object files instead of ".o".
That means when make (or its equivalent built into the IDE in your case) tries to build the program, it looks at those lines to try to figure out how to build myprogram.exe. To do that, it sees that it needs to build myprogram.o, so it looks for the rule that tells it how to build myprogram.o. That says it should compile the .cpp file, so it does that.
Then things break down -- the VC++ compiler produces myprogram.obj instead of myprogram.o as the object file, so when it tries to go to the next step to produce myprogram.exe from myprogram.o, it finds that its attempt at creating myprogram.o simply failed. It did what the rule said to do, but that didn't produce myprogram.o as promised. It doesn't know what to do, so it quits and give you an error message.
The cure for that specific problem is probably pretty simple: edit the make file so all the object files have an extension of .obj instead of .o. There's room for a lot of question whether that will fix everything though -- that may be all you need, or it may simply lead to other (probably more difficult) problems.
A .o object file file (also .obj on Windows) contains compiled object code (that is, machine code produced by your C or C++ compiler), together with the names of the functions and other objects the file contains. Object files are processed by the linker to produce the final executable. If your build process has not produced these files, there is probably something wrong with your makefile/project files.
It is important to note that object files are assembled to binary code in a format that is relocatable. This is a form which allows the assembled code to be loaded anywhere into memory for use with other programs by a linker.
Instructions that refer to labels will not yet have an address assigned for these labels in the .o file.
These labels will be written as '0' and the assembler creates a relocation record for these unknown addresses. When the file is linked and output to an executable the unknown addresses are resolved and the program can be executed.
You can use the nm tool on an object file to list the symbols defined in a .o file.
Ink-Jet is right. More specifically, an .o (.obj) -- or object file is a single source file compiled in to machine code (I'm not sure if the "machine code" is the same or similar to an executable machine code). Ultimately, it's an intermediate between an executable program and plain-text source file.
The linker uses the o files to assemble the file executable.
Wikipedia may have more detailed information. I'm not sure how much info you'd like or need.
Related
I have multiple files in my project which are compiled to object files using either -fPIC or without this option. When compiling those files for the use in a shared library, this option is necessary, else not. Thus when I compile the project into a shared library, this option is necessary.
Nevertheless I never am sure if the last compilation was done into the shared library or not. If not, and I want to compile it into the shared library, the compilation fails, and I have to delete the generated object files. The recompilation of those object files takes quite a lot of time, which I would like to avoid.
Is there a way for the makefile to detect if the object files have been compiled with or without this option right at the beginning, so that either the compilation can continue, or both have to be recompiled, without generating either an error or spending a lot of time in an unnecessary recompilation loop?
Q: "Is there a way for the makefile to detect if the object files have been compiled with or without this option"
Short answer: No
Long answer: if source files can be build with different options and you have to have access to the different builds at the same time, then you must have several output folders. And the makefiles must generate them in the correct folder.
Say something like this for a simple debug/release ("-g" flag) :
|
-src
-include
-BUILD
|
-obj
| -debug
| -release
-bin
|-debug
|-release
Of course, this approach has limitations. For example, if you need to have both "debug/release" and "PIC/not PIC", then you will need 4 output folders.
You can also mix my approach with the one proposed by #BasileStarynkevitch (generating specific names).
A possible approach could be to have your own convention about object files and their naming. For example, file foo.c would be compiled into foo.pic.o when it is position-independent code, and into foo.o when it is not. And you could adapt that idea to other cases (e.g. foo.dbg.o for a file with DWARF debug information, compiled with -g). You could also use subdirectories, e.g. compile foo.c into PICOBJ/foo.o or PICOBJ/foo.pic.o for a PIC object file, but this might be less convenient with make (beware of recursive makes).
Writing appropriate rules for your Makefile is then quite easy.
Be aware of other build automation systems, e.g. ninja.
I'm using code blocks IDE and GNU GCC compiler. when i create a simple program like e.g. add.cpp (for adding two number) it usually creates two file add.exe (executing file) add.o(object file) according to some of them add.o is linked to add.exe while executing.
my question is i deleted the add.o still the add.exe is executing and still producing the required results. how this is possible if the object file is missing ?? and please also explain me what object file really does ??
The object file is linked at compilation time... The object file is then redundant post all the compilation. The o files are maintained between builds so you don't need to rebuild unchanged parts of your application.
From source to executable (in a really oversimplified sort of way):
1) The pre-processor gathers the #include'd files for each .cpp in turn, runs macros, etc, and produces a "translation unit" for each file. These contain all the includes, and the macros have been evaluated: it's otherwise recognisable as source code.
2) The compiler runs over each translation unit, and turns the source into machine-instructions in "object files". These object files contain references (called "symbols") to the functions and variables it has defined, and those that are mentioned but never defined.
3) The linker grabs all the object files, and matches up the symbols across different object files. It then produces an executable.
You can freely run your executable without either the source or object files: these were read in order to produce the next step. Object files are left behind because usually you don't need to rebuild everything each time you press compile: if you only changed one source file, you only need build one new object file, and one new executable.
Files .o are not linked to exe at runtime, they are linked to it at compile time (specifically, during the linking step). Once you have an executable, you can safely remove all object files that were linked into it. It is also OK to remove all static libraries that were statically linked into the exe, because their content becomes part of the executable.
the object file contain the result of the compilation. the exe file contain the result of the link. You can delete the o file if you want exe still working
There are 2 types of linking: static and dynamic. When you compile something the compiler produces object files which are linked statically into your executable. Only if you use an external library and only if you link dynamically against it will you need to have access to it.
The .o file is used for compiling, the .exe. Where the .o is an compiled object code to be later used to compile other programs.
Where as the .exe is the compiled file, and does not require .o.
Given compiling:
g++ -c Hello.cpp -o Hello.o
g++ Hello.o main.cpp -o mainprogram.exe
The first line, creates a .o file but does not do external linking. The second line uses this .o and .cpp file and links your program together.
The only files you require for a program to function that are not in .exe are .so files or .a which are shared and static libraries respectively.
For object file this may help http://en.wikipedia.org/wiki/Object_file
I found one question about compiling and linking in C++ and I don't know which answer is correct. It was discussed with my friends and opinions are divided. Here is a question:
In order to run program written in C++ language its source code is:
(A) compiled to machine code,
(B) compiled and linked to machine code
In my opinion the correct answer is A but I don't have any source to prove it.
Google, first hit.
Linkage is needed as well to create a standalone executable.
You need to link the code you have produced to make it into an executable file. For simple programs, the compiler does this for you, by calling the linker at the end of the compilation process.
The compiler proper simply translates C code to either assembler (classic C compiler) which is then assembled with an assembler or directly to machine code (many modern compilers). The machine code is usually produced as "object files", which are not "executable", because they refer to external units - such as when you call printf(). It is possible to write C code that is completely standalone, but you still typically need to combine more than one object file, and it certainly needs to be "formatted" to the right way to make an executable file - which is a different file-format than an object file [although typically fairly SIMILAR].
Compilation does nothing except creation of object files which means converting C/C++ source code to machine codes.
Linking process is the creation of executable file from multiple obj files. So for running an application/executable you have to also link it.
During compilation, compiler doesn't complain about non existing functions or broken functions, because it will assume it might be defined in another object (source code file). Linker verifies all functions and their existance, so if you have a broken function, you'll get error in linking process
Compiling: Takes input C/C++-code and produces machinecode (object file)
gcc –c MyProgram.c
Note that the object file does not contain all external references!
Linking: Combines object file with external references into an executable file
gcc MyProgram.o –o MyProgram
Note that no unresolved references!
Illustration:
Where libc.a is the standard C library and it's automatically linked into your programs by the gcc.
I've just noticed that your question was about c++, the same concept is in c++ too, if you understand this, you'll understand how it works in c++ too
strictly speaking. Answer A.
But for you to see the whole picture, lets say you have defined some function. Then the compiler writes the machine code code of that function at some address, and puts that address and the name of the function in the object ".o" file where the linker can find it. The linker then take this "machine code" and resolve the symbols as you might heard in some previous error.
I was reading on Clang and Ch (c++ interpreters), but its not clear for me, is it possible to run a newly generated .cpp file without any installations? Because i need to run the final program on any pc...
ps. if yes, does anyone have a good example, where a .cpp file is being executed within c++ code?
This is probably impossible or at least very hard. You would have to include the whole compiler (including linker, assembler, optimizer, preprocessor, ...) inside your program and that would make it extremely big.
One way of doing this is with Clang (as you already noted), there is even a demo project called "Clang interpreter" in the source: http://llvm.org/viewvc/llvm-project/cfe/trunk/examples/clang-interpreter/
However I once tried to compile this "beast" into my program and gave up halfway, because the file size of the result binary (or binaries with external libraries) gets into tens of megabytes (maybe even a hundred).
My suggestion is to either produce a different script (e.g. bash/sh script, which you could execute on any unix machine) that can be interpreted easily.
As far as I know, it is impossible, because compilation process of a CPP file is like this-
Preprocessing: the preprocessor takes a C++ source code file and deals with the #includes, #defines and other preprocessor directives. The output of this step is a "pure" C++ file without pre-processor directives.
Compilation: the compiler takes the pre-processor's output and produces an object file from it.
Linking: the linker takes the object files produced by the compiler and produces either a library or an executable file.
So, there should be intermediate files and executable files.
More can be found here-
https://stackoverflow.com/a/6264256/7725220
Kind of depends on what you mean by "installations".
Yes you can distribute your program with a full compiler, compile the source code and then execute the final result (all from the original exe).
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