Most of the content goes from:
Http://www.linuxidc.com/Linux/2014-08/105302.htm
With VMware installed an Ubuntu virtual machine, the front pit is not filled, and add new pits.
Here's a look at the basic directory structure:
Http://www.linuxidc.com/Linux/2015-07/120815p4.htm
Survival of directory Management to command:
Http://www.linuxidc.com/Linux/2015-07/120815p6.htm
Vim's basic operation: (... )
All right! Start pits!
CTRL + ALT + T open terminal
PWD Displays the current directory
CD Switch Directory
More commands, such as deleting rmdir, RM, etc. are described in the link.
The following is the main explanation for GCC usage:
1. Compilation of individual files
First create a C document password with VIM as follows:
VI hello.c
Suppose the program is:
#include <stdio.h>int main () {printf ("Hello world!\n"); return 0;}
: Wq Save and exit
The hello.c file is saved in the current directory
Enter the password at this time:
GCC hello.c
After running, it doesn't seem to work, type: Ls-al (displays all files and folders in the current directory, including hidden files, and their details)
A a.out file is found in the current directory.
Try running the a.out.
./a.out
At this point the terminal outputs the word "Hello World"
If you do not want each generated executable file to be called a name--a.out
Use the following password:
GCC Hello.c-o Run
-O stands for output
File name of the run output
At this point, enter:
./run
Can get the same effect
2. Compilation of multiple Files
Suppose I have a project that consists of multiple C files, MAIN.C, ADD.C
How to compile this
First of all:
Gcc-wall-c MAIN.C
Gcc-wall-c ADD.C
At this time, the directory will be more MAIN.O, add.o two target files
The role of-C is to compile only the non-link does not generate the executable file
The next step is to link the target files and generate the executable files.
Gcc-wall MAIN.O add.o-o Result
At this point, the current directory has more than one executable file named result
./result
Results can be obtained after running.
The above process looks very cumbersome, can be summed up in a sentence
Gcc-wall main.c add.c-o Result
Effect, but the former better embodies the process of GCC compilation and linking:
After compiling, the target file is generated and the target file is linked to produce the executable file.
3. Static links and dynamic links
Http://www.linuxidc.com/Linux/2014-08/105302p4.htm
This page said very detailed, I also indefinitely copy paste one or two sentences
"The library is actually a set of target files." There are two types of library files on Linux, one is a static link library in . A format, and the other is a dynamic link library in. so format. Let's talk about the static link library. "
ar use format:
ar cr libname.a file1.o file2.o file3.o ...
Note: The prefix lib and suffix in libname.a. A fixed, name is a static link library.
ar cr libtest.a add.o, MINUS.O, DIVIDE.O, multiply.o &N Bsp &NBSP; //consolidate several. o target files into one library
After executing the command, we view the files in the current directory, An extra libtest.a file is created. Next, we use LIBTEST.A directly to recompile the source program:
gcc-wall main.c libtest.a-o result2
The program results are the same as before. We can also use this method:
gcc-wall main.c-l.-ltest-o result2 //Guess the original text here". " The location of the addition may be problematic, the test finds that the-L is followed by the address, "." Represents the current directory, so "." Should be clamped behind-l
Note that the "-L." Above Cannot be absent, because, using "-l", the compiler looks for the system default library file address, not the current directory, it is necessary to use-l to explain the library file address, because our libtest.a in the current directory, so directly use "." Represents the current directory. Later, when we provide third-party libraries to others, if you do not want others to see the source code, then you can only provide. A static link library and a header file containing all function declarations.
A. Static link
In all the previous tutorials, we are the generated target files, static link library and the header file in the same folder, so not only appear very messy, but also inconvenient to manage the source files, once the program's large number of files, the problem becomes more prominent. Let's tidy up the program files, in general, the header files are placed under the Include folder, the static link library Lib folder. First, create two folders and move the corresponding files to the corresponding folder.
mkdir include
MkDir Lib
MV Libtest.a Lib
MV MATH.H include
Since we have packaged four target files (ADD.O, MINUS.O, DIVIDE.O, MULTIPLY.O) into a static link cry libtest.a, you can delete these four files:
RM add.o MINUS.O DIVIDE.O MULTIPLY.O
This is the current directory only left MAIN.C, ADD.C, MINUS.C, divide.c, multiply.c these five source files.
First of all, we use the more troublesome way to compile the source file, the first is to generate the target file, due to ADD.C, MINUS.C, divide.c, Multiply.c These four source code target files have been generated and packaged into a static link library, so we just need to generate the MAIN.C target file:
Gcc-wall-iinclude-c main.cWhen I was testing the Include folder is placed in the programming folder, so it can be written as-lprogramming/include, note the "relative address" concept
here-iinclude-I followed by the main.c referred to in the header file (math.h) address, where the use of the relative address, in fact, can also use absolute address, when due to different Linux systems, their file location may have write differences, which caused our program transplant is very poor, so it is recommended that large The home uses a relative address.
Then link the target file.
Gcc-wall main.o-llib-ltest-o RESULT3
here-llib is the address of the static link library followed by-L, because our libtest.a is in Lib, so we are connected to Lib.
You can see that multiple. c files are generated after the target file, the. o file, can be consolidated into a library file, which is a. A file, which is stored in the project file directory and called from the directory at link time to achieve multiple. o file effects simultaneously.
B. Dynamic links
one of the benefits of dynamic linking is that the same library file resource, which can be shared by multiple programs, can save a lot of memory space. However, when migrating to another operating system environment, if the system does not have a corresponding dynamic link library or set the appropriate path, then the program will not run, which in terms of portability, relative static link is worse. Here 's how to go to the topic:
the suffix of the dynamic link library is. so(on Linux, the. dll is on Windows.) It is named by: libxxx.so,
To Create a method:
gcc-c-fpic a.c B.C ... ....
gcc-shared a.o b.o ....-O libxxx.so
here-fpic: Because the common dynamic link library is different, they load at runtime, so the address is very random, plus the-fpic option, you can ensure that the compiler generated things are address-independent.
we create a libtest.so dynamic link library this time.
gcc-c-fpic add.c minus.c divide.c multiply.c
gcc-shared add.o minus.o divide.o multiply.o-o libtest.so
now, we have generated a libtest.so dynamic link library.
Compile Link:
gcc-wall main.c-l.-ltest-o Run
- L. Indicates that the library file is in the current directory,-ltest is the libtest.so file, note that this is not the runtime, but the process of compiling the link ...
Now that we run the Execute file, we get an error, saying we can't find the libtest.so file.
this is because, when the program runs, the Find dynamic link library file is found under the default system directory. There are two solutions:
First, copy the libtest.so to the/usr/lib directory
Second, modify the path: Export ld_library_path=.: $LD _library_path, add the current path under the path.
The lack of permissions is not successful, but it's probably the concept.
The difference between the dynamic and the static of personal speculation:
A static library is packaged in a software catalog, coexisting with the software ontology, and using a static library to manage the software itself.
Dynamic libraries need to be migrated with the software and configured in the libraries in the current system. At the time of compiling the program, the library of the current system is retrieved, and the corresponding dynamic library file is available. Therefore, the same library file resource, which can be used by multiple programs for sharing, can save a lot of memory space.
The contents of this chapter, simple operation, biased to the basic principle, mainly for the next step to learn makefile preparation.
"Linux Learning Notes" GCC first experience