其实我也不知道是为了啥， 到了现在这种年纪还想学习Linux下的C语言编程。因为我一直就傻傻地认为机会是垂青有准备的人，也一直呆呆地认为活到老学到老。现在Android这么火，各种终端如雨后春笋，而这些终端如果不安装Windows的，势必会使用开源的Linux，而Linux上面跑的程序，C还是占据很大市场的，一旦时机成熟，就可以立马换车改门庭，不至于产生职业耽误。这就是我的这种蠢蠢的初衷。在深圳，特别是现在这个时段，周围的人想到的是如何快速的融入股市，杀进房金融市场，趁着牛市的尾巴赚个盆满钵满，买房买车，迎娶白富美，实现人生的伟大理想。我这种想法似乎十分幼稚，但此时此刻，当我发布这篇随笔时，我的的确确就是这么想的。
回到今天的主题，我今天是想先通过一个简单的Hello,World的程序，然后讲讲Module，讲讲Makefile 等一些非常初级的c编程，如果你很熟悉Linux和C的话，那么你可以选择绕过这篇，或者你可以在后面发表你的建议，欢迎批评指正，但拒绝一上来就乱喷的青子，我们都过了那个年龄了。
首先来看一下我使用的gcc版本
cc -v
或者
gcc -v
至于为什么两个命令得到的是相同的信息gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)呢? 这是因为cc是unix下的编译器，而现在大多数的linux上，都把cc连接到gcc。也就是说cc是gcc的软连接。
1, 开始我们的第一个程序代码编写吧，这里我使用的编辑器是vim
vim hello.c
然后在hello.c里输入
#include <stdio.h>
int main(int argc, char* argv[])
{
prinftf("Hello,World!");
return 0;
}
:wq！出来之后，继续输入
gcc hello.c -o hello.out && ./hello.out
就这么简单，就可以得到我们伟大的Hello, World程序了。
这里我只是补充说明一下上面如果不使用-o hello.out来指定输出的文件名的话，那么gcc会默认生成一个叫a.out的文件出来。那么后面的连接的就应该相应的改成a.out了，也就是
gcc hello.c && ./a.out
当然，如果你觉得这个&& 突兀的冒出来，一时不知是干什么用的话，那么你也可以分成两批去执行，先编译，然后再执行。其实&&的作用就是将两个命令合在一起提交，如果前一个命令如果没有返回错误的话，那么继续执行下一条命令。上面的语句就是编译完hello.c没有错误的话，紧接着就执行刚编译出来的程序。对于我来说，我是喜欢用&&来联接的，我在网上下载下来的源程序也常喜欢make && make install来一步执行。因为我觉得./configure 没有错的话，后面基本上没有啥大问题了，当然这不是绝对。
2， 伟大的Hello,World就完成了。之所以伟大，就是因为其极其简单，武侠小说里面常常也说简单就是实用，比如杨过练的独孤九剑，使用的剑是要比平常人的宝剑要重得的多的，谓之曰重剑不锋。但是一直靠大砍大杀的简单招式去对敌的话，估计也成就不了神雕大侠的。所以还有独孤九式，还有黯然销魂掌等等，所以接下来，我们也来把hello.c改变一点点，注意是一点点，仍然很简单，就是我们让hello.c里的main方法去调用另一个方法。
#include <stdio.h>
int main(int argc, char* argv[])
{
int a=33;
int b=22;
int maxNo=max(a,b);
printf("the max number is %d",maxNo);
return 0;
}
int max(int a, int b)
{
if(a>b) return a;
return b;
}
嗯，上面这段代码最终输出：
the max number is 33.
按照我们的意愿得到了结果，这是一个很好的开端。但是我们想想，如果这个max函数是由别人来协同开发的，两个人不可能都来修改hello.c这个文件吧？如果是那样的话就乱套了，merge 的时候都会把人搞疯的。为了不疯人，为了少抓狂，我们把max这个函数另存进一个max.c文件里去，或者由另一位同事去实现。
这里我讲一下我的操作是这样子的。
vim hello.c
打开编辑，然后再把光标移到int max(int a,intb)的那一行，按5dd得到5行到剪贴板，然后:sp max.c，然后ctrol+w+上光标键，最后按p，将复制的那5行码贴入max.c里，最后:wqa!
分开了两个文件之后，我们的编译就得这样了：
gcc max.c hello.c -o hello.out
最后执行
./hello.out
也可以得到想要的正确结果。
the max number is 33.
3， 嗯，很好，完成了分离了，结果如预期所想。完美解决方案。可是不久之后，又有人实现了一个min.c的模块，并且通知了hello.c去调用一下并显示出最小的数据出来。于是编译相应的就改成了
gcc max.c min.c hello.c -o hello.out
没错，就是将相关的.c文件列举上去就可以，很容易很简单，可是如果项目一旦复杂，.c文件有上千个，那岂不要累死程序员，累死那个发布的同事了吗？当然不可以，我们对于每个人都是不抛弃不放弃。所以我们使用Makefile来解救他们。
#this is a make file for hello.out
hello.out:max.c min.c hello.c
gcc max.c min.c hello.c -o hello.out
那么接下在bash里面直接输入make就可以了。当然，作为第一次使用，我还是没有忘记使用make -v看一下我使用的版本号是多少：
最后执行的结果也是想要的预期结果。
4， 似乎很完美了，可是我们去看看Makefile的内容，总有一种异样的怪怪感。当然如果没有发现也很正常，毕竟我们还只有三个文件，而且现在的机器也是很快的，执行make时也不会有啥差异的。其实如果我们去看网上下载的Makefile 之后，发现很多不怎么变的文件，都会有.o的形式存在的。另外源代码里面可能还充斥着很多.h的文件。那么这些文件是干什么的。为什么会存在这类文件呢？在回答这类问题之前，首先我要申明，不是非要以.o, .h来命名，只不过约定俗成罢了，.o就是模块文件，也就是不常变动的.c 文件可以先编译成.o作为模块保存下来。 .h文件是给调用者说明的，他一般只包含.c文件的方法的签名即可。说得更接近高级语言一点，就是相当于c#(java)里的interface.
接下来，我就把max.c转成max.o, 将min.c转成min.o保存下来。并且生成两份.h文件出来，最后也提供一份更接近生产的Makefile,注意这个M是要大写的，这也是约定，而且这个约定是不能变的。
gcc -c max.c gcc -c min.c
然后max.h和min.h文件输入的内容是：
int max(int a, int b);
和
int min(int a ,int b);
最后的Makefile
#this is a make file for hello.out
hello.out:max.o min.o hello.c
gcc max.o min.o hello.c -o hello.out
max.o:max.c
gcc -c max.c
min.o:min.c
gcc -c min.c
5, 最后，我把我的代码全部贴上来吧。
int max(int a, int b)
{
if(a>b) return a;
return b;
}
max.c
int max(int a, int b)
{
if(a<b) return a;
return b;
}
min.c
#include <stdio.h>
#include "max.h"
#include "min.h"
int main(int argc, char* argv[])
{
int a=33;
int b=22;
int maxNo=max(a,b);
int minNo=min(a,b);
printf("the max number is %d"\nthe min number is %d\n",maxNo,minNo);
return 0;
}
hello.c
6, 关于我的第一个linux的C程序就是这样子的，Happy ending， right?
7, 不，这样的结局并不完美。作为一个程序员，我并没有觉得很happy，因为上面并没有讲到如何调试。都是一次过的简单程序，能够一次性将所有程序逻辑（包括复杂的）写出来就真是大牛逼人物了。 静态的编译错误还好说，make阶段就能发现，可是有些逻辑却不是那么容易发现的。程序员的终极武器debug就要祭出了。在linux里面一般用的就是gdb工具。按照惯例看一下我的版本先：
为了调试我上面的那个小程序，我将所有的*.o文件和hello.out先删除掉。
rm -rf *.o rm -rf hello.out
然后修改Makefile成如下：
#this is a make file for hello.out
hello.out:max.o min.o hello.c
gcc -g max.o min.o hello.c -o hello.out
max.o:max.c
gcc -g -c max.c
min.o:min.c
gcc -g -c min.c
执行make之后。继续输入
gdb ./hello.out
这样就加载了我们hello.out进了内存，而且可以调试了。至于什么是栈内存、堆内存、数据内存，代码内存这些，我就不说了，可以回去翻翻大学教程或者网络上自己搜索一下吧，贴出我的一些简单的调试操作吧：
8, 最后解决一个小问题，就是在上面的图中，我们可以看到其中出现了一个错误说Missing separate debuginfos, use: debuginfo-install glibc-2.17-78.el7.x86_64
其实要解决这个问题，也很简单，直接在bash下面输入
debuginfo-install glibc
前提是我已有/etc/yum.repos.d/CentOS-Debug.repo如下：
# CentOS-Debug.repo # # The mirror system uses the connecting IP address of the client and the # update status of each mirror to pick mirrors that are updated to and # geographically close to the client. You should use this for CentOS updates # unless you are manually picking other mirrors. # # All debug packages from all the various CentOS-7 releases # are merged into a single repo, split by BaseArch # # Note: packages in the debuginfo repo are currently not signed # [base-debuginfo] name=CentOS-7 - Debuginfo baseurl=http://debuginfo.centos.org/7/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-Debug-7 enabled=0 #
CentOS-Debug.repo
如果没有就需要先到http://debuginfo.centos.org/7/x86_64/ 找到与内核完全一样的debuginfo. 例如机器的内核是CentOS Linux 7 (Core) Kenerl 3.10.0-229.el7.x86_64 on an x86_64, 就是在输入用户名的登录时可以看到这个信息。 那么就应该
wget http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-3.10.0-229.el7.x86_64.rpm wget http://debuginfo.centos.org/7/x86_64/kernel-debuginfo-common-x86_64-3.10.0-229.el7.x86_64.rpm
然后rpm安装下载到的rpm包，不过我认为可能不需要下载这两个应该也是可行的。最后仿照配置yum源并执行
debuginfo-install glibc
就可以解决这个问题。
9， 至于如何使用gdb，网上找到两篇介绍文章
http://www.cnblogs.com/hankers/archive/2012/12/07/2806836.html
http://blog.csdn.net/feixiaoxing/article/details/7199643