clang doesn't know about it's installation prefix when searching header files

I configured llvm with

  /usr/src/llvm/svn.llvm/configure \
     --prefix=/usr/src/llvm/dist \
     --with-llvmgccdir=/usr/src/llvm/dist \
     --enable-optimized --disable-debug

When I later compile and install clang, it installs it's own include files in the $prefix:

  $ find /usr/src/llvm/dist -name "std*.h" | tail -n3
  /usr/src/llvm/dist/Headers/stddef.h
  /usr/src/llvm/dist/Headers/stdarg.h
  /usr/src/llvm/dist/Headers/stdbool.h

But clang searches in wrong places:

  $ clang -v main.c --emit-llvm-bc
  ignoring nonexistent directory "/Headers"
  ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin10/4.2.1/include"
  ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin10/4.2.1/include"
  ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin9/4.0.1/include"
  ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/include"
  ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin9/4.0.1/../../../../powerpc-apple-darwin0/include"
  ignoring nonexistent directory "/usr/lib/gcc/i686-apple-darwin8/4.0.1/include"
  ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/include"
  ignoring nonexistent directory "/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../../powerpc-apple-darwin8/include"
  ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.1.3/include"
  ignoring nonexistent directory "/usr/lib/gcc/i386-redhat-linux/4.1.2/include"
  ignoring nonexistent directory "/usr/lib/gcc/i486-linux-gnu/4.2.3/include"
  ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/4.2.3/include"
  ignoring nonexistent directory "/System/Library/Frameworks"
  ignoring nonexistent directory "/Library/Frameworks"
  #include "..." search starts here:
  #include <...> search starts here:
   /usr/local/include
   /usr/include
  End of search list.

This is on Linux (Debian Etch). Maybe llvm::sys::Path::GetMainExecutable
is buggy here?

This is on Linux (Debian Etch). Maybe
llvm::sys::Path::GetMainExecutable is buggy here?

It is indeed buggy. This

  llvm::sys::Path MainExecutablePath =
        llvm::sys::Path::GetMainExecutable(Argv0,
                                       (void*)(intptr_t)InitializeIncludePaths);
+ fprintf(stderr, "MainExecutablePath %s\n", MainExecutablePath.c_str());

says that MainExecutablePath just contains "clang". But on the
shell, it says otherwise:

  $ which clang
  /usr/src/llvm/dist/bin/clang

Unfortunately, my shell (bash) doesn't call the program in a way
so that this can be re-used. A simple test program reveals this:

  #include <stdio.h>
  int main(int argc, char *argv[])
  {
        printf("argv[0] %s\n", argv[0]);
        return 0;
  }

and run it like this:

  $ ./argc
  argv[0] ./argc
  $ mv argc /usr/src/llmv/dist/bin
  $ which argc
  /usr/src/llvm/dist/bin/argc
  $ argc
  argv[0] argc

... I see that using argv[0] is not sufficient, at least not if
bash 3.1.17 handles the PATH.

Only when I specify the full path does argv[] work:

  $ /usr/src/llvm/dist/bin/argc
  argv[0] /usr/src/llvm/dist/bin/argc

So, should I amend llvm::sys::Path::GetMainExecutable so that it:

* check if there is a "/" in the path?
* if not, iterate over env['PATH'] to search for itself and
  use the first match?

"GetMainExecutable" is a tricky function to implement in
cross-platform way. The standard Linux method is to resolve symlink
/proc/self/exe. On Windows, you call GetModuleFileName. See
http://autopackage.org/docs/binreloc/ for extensive discussion.

"GetMainExecutable" is a tricky function to implement in
cross-platform way. The standard Linux method is to resolve
symlink /proc/self/exe. On Windows, you call
GetModuleFileName. See http://autopackage.org/docs/binreloc/
for extensive discussion.

Good hint.

I know that gcc-crosscompiler toolchains (a.g. arm-linux-gcc)
needed to be at an absolute position for a long time (at least
2.95, 3.3.4, 3.4.3). So I want clang to be better here.