autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem locating headers, I think


From: Brian Dessent
Subject: Re: problem locating headers, I think
Date: Tue, 20 May 2008 05:07:03 -0700

[ Please keep replies on the list, that way others can benefit. ]

Robert Rehammar wrote:

> Thank you very much for your reply. The LD_LIBRARY_PATH solved the
> problem with linking, I should have thought of that. Is LD_LIBRARY_PATH
> searched also by gcc, so that if this flag is set, I don't have to set
> LDFLAGS? Regarding the headers, they reside in /scratch/include, but I
> now see that there are two versions of hdf: hdf4 and hdf5 and files
> named hdf.h belongs to hdf4 which I don't use. So everything now works
> as it should. Thank you very much!

No, LD_LIBRARY_PATH is only read by the dynamic linker, it's not
searched by gcc.  You must specify both, because these are two distinct
concepts.  There are in fact (at least) three programs at work:

1. The compiler driver 'gcc', which does not do any linking itself but
acts as a driver to invoke various subprograms with certain options. 
Any -L that you provide to gcc is simply passed on to the linker.

2. The linker 'ld' (sometimes referred to as the link editor) which
performs the task of linking objects and libraries to form an
executable.  This is not part of gcc.  For platforms like linux, it's
part of 'binutils'.

3. The dynamic linker 'ld.so' which performs the task of loading dynamic
libraries at runtime into the program's address space and resolving the
dynamic symbols therein.  This is part of your system's C library (for
linux, this is usually glibc), not gcc or binutils.

As you can see the library must be located by two separate entities: the
link editor at link-time, and the dynamic linker at program runtime. 
The -L flag takes care of the former, and LD_LIBRARY_PATH (and
ld.so.conf) take care of the latter.  And in fact this location can take
on different values at link-time vs runtime, such as when the executable
is linked against an as-yet uninstalled library in the build tree. 
Using the -rpath option hard codes the path into the executable at
link-time such that LD_LIBRARY_PATH doesn't need to be modified, but
this also means that if the library is moved the executable must be
relinked.

Brian




reply via email to

[Prev in Thread] Current Thread [Next in Thread]