c++ /ubuntu about .a and .so - c++

HI,
I would like to ask what is better to use: the .a or the .so file? If i have for example an .so(or .a) and the header.h file can i use these 2 in a test.cpp code without needing the header.cpp? Can i go on a computer just with these 2 and create my own test program?
Secondly I would like to ask if .a is better to use what is the command in ubuntu for creating the .a file? And one more question. Do I necessarly need to use extern "C" class* object() {return new class} in the header.cpp. Or can i use extern"C" in the test.cpp code after i include the .a or .so and the .h file? THX!
The compile command is: g++ test.cpp -o test -ldl (//i dont want to include header.cpp here in the command line when i compile the test.cpp code

.a and .so serve different purposes. One is for statically linking the other one is for shared linking to your library. Search for these terms and you should get a fair amount of answers.

Related

Compile multiple C++ files with SublimeText3

I was using a .bat to compile my C++ files but I would like to find a Build System for ST3 who is able to find alone (throught #include <header.h> ) which files needs to be compiled
I found some build system who can build your C++ files, but only if you put the right name. In that case that's almost easier to edit the .bat file when needed..
Is
#echo off
g++ main.cpp function.cpp -o start.exe
start.exe
pause
a good g++ syntax?
Do someone have the solution?

Not Getting .a File From Compiling Static Library C++ (Linux Kernel) [duplicate]

This question already has answers here:
How does "make" app know default target to build if no target is specified?
(4 answers)
Closed 2 years ago.
I am trying to compile a static library of the sorts:
foo.c
foo.h
My makefile looks like:
foo.o: foo.c
cc -c foo.c
libfoo.a: foo.o
ar -rv libfoo.a foo.o
I just call make from the directory.
It compiles the .c file and gives a .o file, however, I don't get a .a file. Although, I can run the exact commands sequentially and get the .a file.
I'm sure it's something simple I'm messing up. I've looked all over but the examples aren't really helping as they're much more intricate than my circumstance.
Just calling make without parameters will by default use the first goal, which is foo.o. Since that does not depend on libfoo.a (and why should it of course), the second recipe is never triggered.
The result is a .o file but no .a file.
From https://www.gnu.org/software/make/manual/html_node/Goals.html
By default, the goal is the first target in the makefile
If for any reason you are forced to use make as just make, then reorder the parts in your makefile, to ensure that the first target is the one you need.
Alernatively, as described on the same page a few lines later
You can manage the selection of the default goal from within your makefile using the .DEFAULT_GOAL variable (see Other Special Variables).

Make G++ use my lib automatically

I have an already built library made of this files:
A bunch of headers.
A .so file (libmylib.so).
I want to compile a c++ program (sample.cpp), where I included the headers, and where I need to use the library. This is what I've done, and it's working:
Put the headers in usr/local/include.
Put the .so file in usr/local/lib.
Compile the program in this way: g++ sample.cpp -lmylib.
My question is: why is it not working if I omit -lmylib from the last line?
Is there a way to install the library such that I don't need to put it every time in the g++ command?
Thank you.
What libs are used by default depends on some setting in the compiler/linker,
but it´s not "every lib in usr/local/lib" or any directory, just some specific names
(or even just a single one). Call g++ -v or g++ -dumpspecs to list it (and more stuff)
So, either rebuild your compiler with your own lib list, or specify it manually everytime.

Confused about C++ #include

My project has this folder structure:
Project/
--Classes/
----Class1.h
----Class1.cpp
--main.cpp
"Class1.h" contains method definitions, "Class1.cpp" is the source code for "Class1.h".
The source code of "Class1.h" is like this:
class Class1 {
public:
void do_something();
};
The source code of "Class1.cpp" is like this:
#include "Class1.h"
void Class1::do_something() {
//
}
The source code of "main.cpp" is like this:
#include "Classes/Class1.h"
int main(int argc,char** args) {
Class1* var = new Class1();
var->do_something();
return 0;
}
However, when compiling "main.cpp", the compiler doesn't know where the implementation of methods in Class1 is, so it shows linking error about undefined reference.
Do I have to add any path into the command line so the compiler knows what source files it has to compile? How to tell the compiler that it must compile "Class1.cpp" also?
You need to feed all files in your project to the compiler, not just "main.cpp". Here you can read about the basics of compiling multiply files together with Gcc.
Another option would be to compile your classes as a dynamic or static library, but you should start with simply compiling them together if you're not quite familiar with libraries.
You need to know about building (compiling and linking) C++ applications. This topic usually don't describe in programming books about C++ and only way to do it - google and programming community sites with articles.
Fast answer is:
g++ -c Classes/Class1.cpp -o Class1.o
g++ -c main.cpp -o main.o
g++ Class1.0 main.0 -o ProjectName
It's a simple set of commands to compiling and linking program. Usually it would be done by build system (make, qmake, cmake, waf, scons, ant etc). Also, IDE can build program without additional configuration, Visual Studio for example.
The correct way to do it is doing the header inclusion in the Class1.cpp file. That way if the Class1.cpp is compiled as a library, you can use the header file to get the declarations.
The other way around, if you will directly use the Class1.cpp, compiling it with your project. You should include Class1.cpp in your main.cpp.

C++ linking to libraries with makefile (newbe)

I'm trying to understand how to use non standard libraries in my C++ projects.
I have a few questions.
Lets say I want to use POCO library. So I downloaded it and build it using make (static build). Now I have bunch of .o files and .h files.
There is a Path.h file and a Path.o file in different directories.
Now I want to use this module in my code. So i include the file using #include "Poco/Path.h". Do I have to modify makefile and add Path.o to my target ?
What happens when I use standard library ? Are those available only in header files ? I know that template code cannot be precompiled. What about the rest ?
Besides the .h and .o files, you will probably also have one or more libXXX.a and/or libXXX.so files. These are the actual library files that your application should link against.
To use the library, you include the relevant headers in your source file, and you change your makefile to tell the linker that it should also link your application to the XXX library.
The typical linker-command for that is -lXXX and the linker will look for both libXXX.a and libXXX.so and use whichever seems most appropriate.
The standard library is not really different from external libraries, except that you don't have to specify it explicitly to the linker.
Your question seems to imply that you already have a makefile for your own code. If that's the case, then yes, you should modify the rule for your executable in that makefile. As Bart van Ingen Schenau points out, the POCO makefile probably assembled the objects files into libraries such as Poco/Libraries/libPoco.a, so you should use them instead of trying to pick out the object files you need. For instance, if right now your rule reads:
foo: foo.o bar.o
g++ -lSomeLibrary $^ -o $#
you should change it to
foo: foo.o bar.o
g++ -lSomeLibrary -LPoco/Libraries -lPoco $^ -o $#
(The second part of your question, "What happens... What about the rest?" is unclear to me.)
Note: It's a bad idea to #include "Poco/Path.h". This makes your code dependent on a directory structure, something it should not care about. It is much better to #include "Path.h" and tell the compiler where to find it: g++ -c -IPoco ....