c_include_path VS LD_LIBRARY_PATH [英] c_include_path vs ld_library_path

问题描述

在任何Ubunutu 12.04或斯普林代尔6.4，使用gcc和g ++，有什么 C_INCLUDE_PATH 之间的差异（或 CPLUS_INCLUDE_PATH ）和 LD_LIBRARY_PATH ？是 LD 壹只在运行时使用，另外两个只在编译时？

On either Ubunutu 12.04 or Springdale 6.4, using gcc and g++, what's the difference between C_INCLUDE_PATH (or CPLUS_INCLUDE_PATH) and LD_LIBRARY_PATH? Is the LD one only used at run-time, and the other two only at compile-time?

由于包含和 LIBRARY_PATH 环境变量似乎是由GCC在这些操作系统上忽略了，这是我应该构建我的〜/ .bashrc文件时，使其便携横跨现代的Linux操作系统能够（实际路径模的变化）设置？

Since the INCLUDE and LIBRARY_PATH environment variables seem to be ignored by GCC on these operating systems, which should I set when constructing my ~/.bashrc file to make it as portable as possible (modulo changes in the actual paths) across modern Linux OSes?

推荐答案

LD_LIBRARY_PATH是一个环境变量，告诉哪些目录的DLL加载器应该找动态库，当您启动一个可执行文件。该变量是危险和去precated

LD_LIBRARY_PATH is an environment variable which tells in which directories the dll loader should look for dynamic libraries when you start an executable. The variable is dangerous and deprecated

LIBRARY_PATH - 告诉连接器，其中也找图书馆在构建EXE或LIB
INCLUDE_PATH - 告诉到哪里寻找在#include语句称为文件

LIBRARY_PATH - tells linker where too look for libraries while building exe or lib INCLUDE_PATH - tells where to look for files referred in #include statements

在任何情况下，LIBRARY_PATH和INCLUDE_PATH应当在一个特定的叠合系统设定，而不是在bashrc中。较容易的脚本可以建立C-来源，更可能你的电脑可能感染了rootkit的。

In any case, LIBRARY_PATH and INCLUDE_PATH should be set in a particular build-system, not in bashrc. The easier a script can build c-sources, the more probable your PC may be infected with a rootkit.

BTW：GCC是调用正确的编译器（例如CC或g ++）和连接器的包装。
     G ++是GNU C ++编译器

BTW: gcc is a wrapper which invokes a proper compiler (e.g. cc or g++) and linker. g++ is gnu c++ compiler

修改
解释，为什么LD_LIBRARY_PATH是危险的。

EDIT Explanation, why LD_LIBRARY_PATH is dangerous.

我没有使用过的Linux几年，我不知道，这ENV变量仍​​处于电流分布。我使用Linux的时候（2006年左右），因为它提供了非常容易被利用钩它被认为是德precated。

I haven't used Linux for a couple of years and I wonder, that this env-variable is still in current distributions. It was considered as deprecated when I was using Linux (around 2006) as it provides very easy to exploit hook.

它的问题是，它prescribes路径的，其中ld.so的顺序 - 动态链接程序查找所需的库。如果LD_LIBRARY_PATH包含一个可写目录，黑客（在新的语音网络罪犯）可以在该目录放置在系统目录（例如/ usr / lib目录）被发现可能是一个名称的库。这个库可以首先做任何肮脏的工作，然后调用原来的库。利用LD_LIBRARY_PATH更容易然后在系统目录妥协二进制文件。而且这种攻击是防不胜防。

The problem with it is, it prescribes the order of path's in which ld.so - dynamic linker looks for required libraries. If LD_LIBRARY_PATH contained a writable directory, a hacker (in new speech a cybercriminal) could place in that directory a library with a name likely to be found in a system directory (e.g. /usr/lib). This library could first do any dirty job and then call the original library. Exploiting LD_LIBRARY_PATH is much easier then compromising binaries in system directories. And also such an exploit is hard to detect.

这篇关于c_include_path VS LD_LIBRARY_PATH的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！