I use netbeans and notice that in addition to creating the .o files, it also creates .o.d files. What are these files (.o.d) for?
As described by Netbeans: Dependency files.
Build systems try to make it so that if you recompile, you save effort by not recompiling translation units whose generated object file will be identical. So it only attempts to recompile files that have changed, or files that maybe haven't changed but a file they depend on has changed. The .o.d files track which files the .o depends on so that it can quickly determine what needs to be recompiled if you build your project again.
Related
I have a huge legacy code project that I want to clean up a little. I know for a fact a couple of files are not actually being used. The project is based on CMake. But there are more than 15 targets with lots of dynamic variables containing source file paths, so reading the CMakeLists.txt manually is tricky.
So can I produce a list of unused files automatically after a CMake build?
We should be able to get a list of the used .cpp source files after the build, and I bet we can deduct this from an e.g. find ... command.
Note: here I refer to unused files as source files that aren't compiled into a target. Ideally I would also want the unused .h header files, but I bet that's outside the CMake scope.
how can I add *.h file with it's own compiled *.o file to my project, so I can use it's functions etc. I'm using codeblocks and trying to set paths for compiler & linker but it still can't recognize the functions.
I take it that you have a .h file and .o file all ready from another project, and wish to add them to your current project, but want to keep the .o definitions hidden from the external users of your current project.
Add your .o file to your current project, and make sure it physically exist in your linker path. Then add the .h file to this project, and make sure it exists alongside your sources (not inside the include folder), and make sure it exists inside your compiler path.
Right-click the .o file and click on Properties. Then navigate to the Build tab, and check off 'Link file'.
Right-click your current project, and click on Build options. Then in the general build configuration, add -lNAMEOFOBJECTFILE.o to your linker options.
Now... this is not a typical pattern in C++ and I advise you look into creating a shared library that has the 'hidden' code you wish to use, and link your final binary against a .dll/.so. Also, if the .o file uses any external dependencies, then this will not work for you, so the suggested route I recommend, is building a shared library file, then linking against that. When you release your code, you can always omit include .h files that have symbols that you want to keep hidden in your final API.
Good luck!
Be warned I am new to C++.
When I compile my program I notice that there is an .obj created for every class that I have. When I looked at other programs in my program files, I realized that these programs barely had any .obj's so I guess that I am doing something wrong.
Also if I deleted the obj files from the release directory and tried to run the exe again and it still worked exactly as before, I know these files can't be pointless but...
What is their use? Should it make them for every class file? - if not how do I resolve this?
How do I put them in one directory like a folder called obj when I compile?
.obj files (.o files on Linux/Unix) are compiled source files, there will indeed be one for each .cpp file, or more formally "compilation unit". They are produced by the compilation phase of building a project.
These .obj files are then combined by linker either to an application, usually .exe file on Windows, or a library file, which on windows can be a .dll for dynamic library, or .lib for static library (which is basically a collection of .obj files in one packed into one file, see below). On Unix-like platform application usually has no extension, and dynamic library has .so extension, and static library has .a extension.
You do not see .obj files or static .lib files with programs, because they are not needed at runtime, they are used only by linker. When you run the linking phase of building a project, linker combines all the needed .obj files into .exe and .dll files (or equivalent), which are used at runtime.
Obj files are generated after compiling. The compiler generates them with many information. Then the linker generates an executable with other files, thus those OBJ files are not necessary anymore.
A very extended answer can be found in any C++ book.
There is no problem. But if you delete them you will force your compiler to compile some files that had no changes but have no OBJ file anymore. Be aware of that.
Just forget about them if you are still working in your code.
Object files are generated by compiling your code. They take your code and convert it to machine code so that the computer can understand and implement your solutions. Once the object files have been generated (a object file is generated for every .cpp file), all the relevant object files are used by the compiler to build a executable file. The executable can then be run independant of the object files, and the object files may be deleted. If another executable were to be created, object files for the relevant code would be necessary again.
Hope it helps!
When using .a files, do I have to distribute the .cpp files with it or just the .h files?
For example, I wrote a large amount of classes and compiled all the code into .o files. I then archived the .o files into .a files.
When I attempt to use the .a files with the .h files in other projects, it requires me to have the .cpp file sometimes.
For some of the headers, it doesn't ask me for the .cpp files but for stuff like sockets it gives undefined references to impl_shutdown unless I include the .cpp file.
This happens even though I link all necessary libs.
Why? What are .o/.a files really and why do I need to distribute the .cpp files with it? Libraries like Zlib and LibPng don't seem to have to distribute anything but the .h and the .a files.
When using .a files, do I have to distribute the .cpp files with it or just the .h files?
Only the headers.
What are .o/.a files really
.o files are object code, .a are archives (collections of object files). They're compiled and assembled machine code, that need to be linked in order an executable file to be created.
and why do I need to distribute the .cpp files with it?
You don't.
Just the libraries and the headers will be fine.
Make sure that if your objects are over multiple libraries, there are no circular dependencies. If there are, you need to specify the libraries multiple times in order for the linker to pick them up.
I am new to Linux environment, and I just started using gcc. We have small project that has 7 to 8 cpp files. When I try to compile my files, I wonder why there is .o file for every .cpp file. There is only one main.
This is the way compilation works. Each translation unit gets turned into object code ( the .o files) then the object files get linked together and with other libraries into the final executable file. Normally the build system hides object files somewhere, but you're probably using a very simple build system or script which doesn't bother.
.o is an object file created during compilation of each cpp.
for more info Why Compile to an Object File First?