在 Ubunutu 12.04 或 Springdale 6.4 上,使用 gcc 和 g++,有什么区别C_INCLUDE_PATH
(or CPLUS_INCLUDE_PATH
) and LD_LIBRARY_PATH
?是个LD
一个仅在运行时使用,另外两个仅在编译时使用?
自从INCLUDE
and LIBRARY_PATH
在这些操作系统上,GCC 似乎会忽略环境变量,在构建 ~/.bashrc 文件时我应该设置哪些环境变量,以使其在现代 Linux 操作系统中尽可能可移植(实际路径中的模数更改)?
LD_LIBRARY_PATH 是一个环境变量,它告诉 dll 加载器在启动可执行文件时应在哪些目录中查找动态库。变量是危险且已弃用 http://xahlee.info/UnixResource_dir/_/ldpath.html
LIBRARY_PATH - 告诉链接器在构建 exe 或库时在哪里查找库
INCLUDE_PATH - 告诉在哪里查找 #include 语句中引用的文件
无论如何,LIBRARY_PATH 和 INCLUDE_PATH 应该在特定的构建系统中设置,而不是在 bashrc 中。脚本构建 c 源代码越容易,您的 PC 感染 rootkit 的可能性就越大。
顺便说一句:gcc 是一个包装器,它调用适当的编译器(例如 cc 或 g++)和链接器。
g++ 是 gnu c++ 编译器
EDIT解释一下,为什么 LD_LIBRARY_PATH 是危险的。
我已经有几年没有使用 Linux 了,我想知道这个环境变量仍然存在于当前的发行版中。当我使用 Linux 时(大约 2006 年),它被认为已被弃用,因为它提供了非常容易利用的钩子。
它的问题是,它规定了 ld.so - 动态链接器查找所需库的路径顺序。如果 LD_LIBRARY_PATH 包含可写目录,则黑客(用新的说法是网络犯罪分子)可以在该目录中放置一个可能在系统目录中找到的名称的库(例如 /usr/lib)。这个库可以先做任何肮脏的工作,然后调用原始库。利用 LD_LIBRARY_PATH 比破坏系统目录中的二进制文件要容易得多。而且这种漏洞很难被发现。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)