c_include_path vs ld_library_path
在Ubunutu 12.04或Springdale 6.4上，使用gcc和g ++， C_INCLUDE_PATH （或CPLUS_INCLUDE_PATH ）和LD_LIBRARY_PATH之间的区别是什么？ LD只在运行时使用，而其他两个只在编译时使用吗？
由于这些操作系统上的GCC似乎忽略了INCLUDE和LIBRARY_PATH环境变量，我应该在构建我的〜/ .bashrc文件时将其设置为使其在现代Linux操作系统中尽可能可移植（实际路径中的模数更改）？
LD_LIBRARY_PATH是一个环境变量，它告诉dll加载器在启动可执行文件时应该在哪些目录中查找动态库。 该变量是危险的并且已弃用
LIBRARY_PATH – 告诉链接器在构建exe或lib时查找库的位置INCLUDE_PATH – 告诉在哪里查找#include语句中引用的文件
在任何情况下，LIBRARY_PATH和INCLUDE_PATH都应该在特定的构建系统中设置，而不是在bashrc中。 脚本可以更容易地构建c源，您的PC可能感染rootkit的可能性越大。
BTW：gcc是一个包装器，它调用适当的编译器（例如cc或g ++）和链接器。 g ++是gnu c ++编译器
编辑解释，为什么LD_LIBRARY_PATH是危险的。
我已经几年没用过Linux了，我想知道，这个env变量仍然是当前的发行版。 当我使用Linux（大约2006年）时，它被认为已被弃用，因为它提供了非常容易利用的钩子。
问题在于，它规定了路径的顺序，其中ld.so – 动态链接器查找所需的库。 如果LD_LIBRARY_PATH包含可写目录，则黑客（在新演讲中为网络犯罪分子）可以在该目录中放置一个名称可能在系统目录中找到的库（例如/ usr / lib）。 这个库可以先做任何脏工作，然后调用原始库。 利用LD_LIBRARY_PATH比破坏系统目录中的二进制文件要容易得多。 此类漏洞也很难被发现。