c_include_path vs ld_library_path

Question

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?

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?

Answer 1

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 - tells linker where too look for libraries while building exe or lib INCLUDE_PATH - tells where to look for files referred in #include statements

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 is a wrapper which invokes a proper compiler (e.g. cc or g++) and linker. g++ is gnu c++ compiler

EDIT Explanation, why LD_LIBRARY_PATH is dangerous.

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.

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.