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.
Related
How are we supposed to create a DLL, included with header files?
For example, a project using the raylib game library requires raylib.dll to be present with the output file.
The raylib.dll is included with the header files of the raylib game library.
Is that how are supposed to create a DLL and include header files into it?
I am using Dev C++ with a GCC compiler.
There's only a limited relation between the header files and the creation of the DLL. In particular, you use the word "linked", and header files are not linked. Header files are included, libraries are linked. Including happens before a compile, linking afterwards.
Header files can provide declarations for functions defined in the DLL. That tells the compiler that those functions actually exist (somewhere), so the compiler will ask the linker to find those functions. The linker in turn will find them in the library.
I'm kind of a noob in these things.
I have a .cpp file that uses functions from a .lib library (and its relative .h header file). In CLion I manage to run the program fine, but I need to compile it as a .so library because I want to use the functions defined in the .cpp in a python program.
Do you guys know how to do it?
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.
I am learning how to compile libraries and want to compile the fltk library for example.
To compile a static library I need .h and .c files and just compile them, but the library has not only many .h and .c files, but some other files I don't know what to do with them. In a folder called "src" with .c files there are some .h files, .xbm, .xpm, .fl and etc. including "Makefile" that maybe can help me I suppose.
So, how to do it right?
How about using the build system that came with the library?
Sounds like it's expecting you to run make.
But even if it was using something else, like CMake or SCons, it still seems like the best option would be to just use what it expects rather than trying to import it into some other build system.
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!