about LD_INCLUDE_PATH

nocturna_gr · 07-20-2009, 05:20 AM

Hi,
a couple of questions about LD_INCLUDE_PATH. I export it from my "/root/.bashrc"
1/When gcc is executed, is LD_INCLUDE_PATH automagically included in the compilation process or must i do "-I${LD_INCLUDE_PATH}"?

2/I have tried the "-I${LD_INCLUDE_PATH}" solution, but although i DO include ALL corresponding paths, compiler still complains about "a couple" of missing header files. The problem is solved if i separately do "-Ipath" for the corresponding directories. Possible causes?

Thank you

ntubski · 07-20-2009, 09:06 AM

LD usually refers to the linker, so it seems odd to call the place where you put your includes as the LD_INCLUDE_PATH.

Quote:

1/When gcc is executed, is LD_INCLUDE_PATH automagically included in the compilation process or must i do "-I${LD_INCLUDE_PATH}"?

According to the Environment Variables section of the gcc manual, gcc uses CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, and OBJC_INCLUDE_PATH for finding includes.

Quote:

2/I have tried the "-I${LD_INCLUDE_PATH}" solution, but although i DO include ALL corresponding paths, compiler still complains about "a couple" of missing header files. The problem is solved if i separately do "-Ipath" for the corresponding directories. Possible causes?

I don't think the -I option handles multiple directories.

paulsm4 · 07-20-2009, 10:49 AM

1. The "-L" switches you specify (at link time) can be overridden by the $LD_LIBRARY_PATH you specify (at runtime).

2. The converse isn't true: $LD_LIBRARY_PATH is *not* used during linking.

3. Compile-time includes ("-I") have nothing to do with linking.
"-I" is completely unrelated to either "-L" or "$LD_LIBRARY_PATH".

nocturna_gr · 07-20-2009, 12:03 PM

First thnx everybody. Sorry paulsm, but my small experience makes it difficult to understand

Quote:

Originally Posted by paulsm4

1. The "-L" switches you specify (at link time) can be overridden by the $LD_LIBRARY_PATH you specify (at runtime).

By "overriden" you mean automatically, or by doing "-L${LD_LIBRARY_PATH}"? If yes isn't there a problem with multiple directories, as ntubski said?

Quote:

2. The converse isn't true: $LD_LIBRARY_PATH is *not* used during linking.

If it points to libraries and bin code, what is the meaning during compile time?

Quote:

3. Compile-time includes ("-I") have nothing to do with linking.
"-I" is completely unrelated to either "-L" or "$LD_LIBRARY_PATH".

ntubski · 07-20-2009, 02:42 PM

Quote:

By "overriden" you mean automatically, or by doing "-L${LD_LIBRARY_PATH}"? If yes isn't there a problem with multiple directories, as ntubski said?

Thus 'The "-L" switches', not '"-L" switch'.

Quote:

If it points to libraries and bin code, what is the meaning during compile time?

-L tells gcc where to find libraries, so the linker can see what symbols the library defines. For shared libraries (.so, similar to .dll on Windows), the library has to be found at runtime as well. That's where LD_LIBRARY_PATH is used (more info at 3.3.1. LD_LIBRARY_PATH).

So to sum up:

use -I, CPATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, or OBJC_INCLUDE_PATH for finding .h include files at compile time.
use -L or LIBRARY_PATH to find .a or .so library files at compile (more accurately link) time.
use LD_LIBRARY_PATH to find .so library files at runtime. I seem to remember there is a -R option that does something like this, but I can't seem to find it in the manual now.
LD_INCLUDE_PATH doesn't do anything.
multiple paths in variables are separated by ":".
-I and -L take one path at a time.