make,config,gcc对于CC,CFLAGS的理解

对于make来说，他的Makefile内部分别针对CC，AR，RANLIB，STRIP，INSTALL，CPPFLAGS，CFLGAS，LIBS，LDFLAGS有自己的维护，你可以通过

make CC=xxx的方式来直接覆写CC变量来完成交叉编译，或者make CFLAGS=xxx，make LDFLAGS=xxx的方式来添加编译参数和链接参数。

对于configure来说，他自身实际是一段shell script，我们观察可以发现，他内部对于CC，CFLAGS等的维护是通过取环境变量的方式来取得，也就是说你需要将CC放在configure的前面

CC=xxx ./configure或者CFLAGS=xxx ./configure来改变他的变量从而改变之后的Makefile,如果你试图通过像类似

./configure CC=xxx的方式来进行配置你会受到系统提示错误，提示configure命令没有CC这个选项，显然他是把他当成命令参数了。还有就是有的configure比如Dropbear在交叉编译的时候会需要你指定zlib的位置，此时在你输入--with-zlib=xxx的时候，你其实也是在Makefile中写入了LDFLAGS，此时如果你在configure之前还同时设置了环境变量，也就是说你输入了LDFLAGS="-Wl,--verbose" ./configre --with-zlib=xxx,你最终的Makefile其实是同时拥有了这两个flag,他是一个追加的过程不是一个覆盖的过程。

其实也就是说从configure->Makefile的过程中，configure通过现在获取的环境变量CC来直接写入到Makefile中，但同时如果你也可以在后期make的同时，重新make CC=xxx来破坏之前configure给你CC设定的初始值。

gcc就不用说了，很显然，这几个变量只是针对最终的Makefile用来make的，跟gcc其实没什么关系。但最终在Makefile中用到的时候，还是gcc（CC）加上这些事先设定好的值罢了。

所有一点要特别注意的就是，其实在Makefile中已经针对CC，AR，RANLIB，STRIP，INSTALL，CPPFLAGS，CFLGAS，LIBS，LDFLAGS都有了自己的定义，但如果你仅仅在make的时候设置了一把CC=unicore32-linux-gcc你就认为高枕无忧可以交叉编译的时候，你就错了，因为这些变量仅仅只有CC被你改变了，此时你的ld其实还是x86平台下的，所以会出现一系列平台相关性错误，因此如果你想批量修改的话，你还是重新configure吧。

还有就是命令追加，有些同学可能不想破坏Makefile里的LDFLAGS,想的很天真,想在make的时候不进行覆盖而进行追加，也就是说make LDFLAGS+=xxx,以为万事大吉，但这是没有意义的，Makefile在处理完LDFLAGS之后还是会被外层你手动给make设置的环境变量的给替换，所以如果你想同时通过外部环境+内部Makefile同时来控制LDFLAGS，这其实是做不到的。

关注【编编成程】，这里都是我的原创经验，希望你会喜欢