I want to create a class say PEN in one one c++ file and inherit it in another class that is in a separate file and finally run the program from a C++ file that has only the main function. I know this is a basic thing but I am new to C++. The program is a console program.
There's a few things here.
. Referencing
. Compling
. Linking
Referencing
You put your classes and main function in separate .cpp files.
Each file that references a class in another file needs to #include class.h where class.h is the headers that include the class declarations. You can have a single shared header for all the files, or a separate one for each. Usually there is a .h for each .cpp with the same name by convention.
Compiling
Then when you complie, you need to decide if you want a single binary blob (for you, this is my recommendation) or a library to link to.
Not sure exactly the cpp compile options but it will be something like: path/to/cpp-compiler main.cpp class.cpp
Order is important here, the classes main.cpp needs must be specified AFTER main.cpp on the command line.
Linking
If you chose to compile a separate library, you will need to do:
path/to/cpp-compiler
-c class.cpp
path/to/cpp-compiler -c main.cpp
separately, then do:
path/to/cpp-compiler -o a.out main.cpp class.o
to link.
You can also pack multiple .o files into a .so or dll if you like and link to that.
Linking can become quite complex and has many quirks so I think stick with compiling all you sources together for now until you get more familiar with it.
This is a good answer here: Using G++ to compile multiple .cpp and .h files
I suggest you do a little more research as there are bound to be heaps of other answers to this question.
Related
I'm having problems creating a lib and using it to link a .c-file with a main-function.
I have e.g.
cfile1.c
cfile2.c
cfile3.c
program.c (with main-function)
I want to create a library from all the .c-files and use it to link the
program.c
What is the best way to do that?
I assume your program.c (which is main) need those *.c files(support) to make a new library. If is that so, may be you should compile all of them because your program.c need that (if there is a function on *.c files called on program.c files)
I think, you can take a look on this link below:
Including one C source file in another?
Hope it helps, CMIIW
How do I create a custom library in GNU? What I mean is:
When we use #include < stdio.h> and printf
we can compile it with gcc main.c
Now I create my custom headers and .a/.so library files, I know I can set the environment variable C_INCLUDE_PATH and include my header files with #include<> instead of #include"". However, I still have to compile it with
gcc main.c -o program -L/whatever/ -lwahtever
(with set environment variable if using .so)
Is it possible to make it behave like #include< stdio.h> where I don't need to include the paths with corresponding command line arguments?
You actually don't need -L/whatever/, just -lwhatever. The first option supplies the path to your library, but you have already taken care of that with the #include and modifying C_INCLUDE_PATH. The second option tells the linker which library to link your executable with. An example of this is when using functions from the C math library, you #include <math.h>, but to compile, you still need the linker option -lmath. So to answer your question, no. You can remove the first option, but you must leave the second.
ar can create an .a file which includes another .a file, such that the output of ar -t whatever.a looks like:
someotherarchive.a
foo.o
bar.o
However, if this archive is then linked, the symbols from an .o in someotherarchive.a will not be accessible by foo.o. This can be resolved by flattening with the T switch to ar when creating, but that also creates a thin archive. Since there does not seem to be a flatten-but-don't-thin option, it's necessary to extract from someotherarchive.a first and then link the .os independently to create something that contains:
otherarchivememberA.o
otherarchivememberB.o
foo.o
bar.o
Raising the question, if putting one .a inside another .a makes it inaccessible, what's the purpose of doing so?
Presumably this is because ar was historically a general purpose archiving tool, like tar.
In other words, there is no purpose to inaccessibly nesting archives if you are creating static libraries.
When running make on one of my C projects I'm playing around with, I notice that gcc produces different file types at stages. I'm curious as to what these are, as I'm not too familiar with gcc.
The extensions I noticed are:
.o (I understand that these are compiled libraries)
.o.lst
.d
.a
I hope this is not a silly question, but I'm just trying to understand these files, and what they're used for.
.o is object file ie machine dependent output code
use gcc -c
.a is static library ... collection of several o files
ar -r
.d file is the dependency file that contain the dependency
.lst -If you want to see the C code together with the assembly it was converted to, use a command l
gcc -c -g -Wa,-a,-ad [other GCC options] foo.c > foo.lst
I have a legacy code written using fortran 77. I'm trying to build it with gfortran. But I seem to be failing at the stage where I include the libraries in the build. The dozens of *.f source files compile fine, but when they are being linked, I get a bunch of "undefined reference" errors all relating to subroutines and functions that are defined in my libraries. I already ran the makefile for the libraries first, so the variables I need should all be exported. I'm playing with the "-L" option, but can't get it to work as desired.
First, here's my syntax of the linking line in my makefile:
29 $(PROGRAM): $(SRCS) $(LIBS)
30 $(FC) $(FLFLAGS) -o $# $+ -L$(DIRLIB)
PROGRAM is the program name, SRCS are all the compiled source files, LIBS is set to two different files - an archive file (file.a) and a file.o file.
FC is gfortran, I don't have any specific linking flags for FLFLAGS as of now, and DIRLIB is the main directory of the libraries.
The thing is that my *.o files that resulted from building my librarires don't reside in just the main directory, DIRLIB. DIRLIB contains several directories, all with their own *.o files that are needed by my code.
I tried adding each individual directory after the -L option (e.g. DIRLIB/DIR1/*.o DIRLIB/DIR2/*.o DIRLIB/DIR3/*.o), but I eventually start getting errors that some subroutines are multiply defined.
All this business of user-defined libraries and archive files just confuses me and I'm pretty new to making makefiles in the first place, so I'm just taking a shot in the dark here that somebody might be able to help me shed some light on this.
Libraries need to come after the .o files that reference them in the linking command.
I'm guessing the object file in LIBS comes after the library, but needs some of the procedures from it. Can you show the command that is actually run (with all variables expanded), to confirm this?
I tried to build this code again using the library. It worked this time. I'm pretty sure I'm doing the same thing in my makefile as I did before, so it must be related to the library I had. Maybe somebody altered it along the way and inadvertently broke it. But I got a fresh clean copy of the library. My steps are to:
1) run the makefile for the library source files; it creates a library.a archive file
2) run my code makefile:
it has a line to specify the location of this archive file and assign it to "DIRLIB"
DIRLIB := ../library
then the linking command of the makefile becomes
$(FC) $(FLFLAGS) -o $# $+ -L$(DIRLIB) -lskit
FC is my compiler, FLFLAGS are my linking flags, -L is the option specifying the location of libraries to be included and -lskit is a crucial option which appears to allow the use of F77 libraries... without the -lskit option, I get many undefined reference errors. It may have been that last time I was not including this -lskit option at the end.