Re: C++ include files ``gone''?

[Michael Poole <poole at troilus dot org>]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> I just realized another problem. I do not call g++ directly, but have a
> symlink from ~pfeifer/bin/g++ to $prefix/bin. And, believe it or not:
> 
>   ignoring nonexistent directory "/home/pfeifer/bin/include/g++-3"
>   ignoring nonexistent directory "/home/pfeifer/bin/lib/gcc-lib/i386-unknown-freebsd4.1/2.97/include"
>   ignoring nonexistent directory "/home/pfeifer/bin/i386-unknown-freebsd4.1/include"
>   ignoring nonexistent directory "/sw/test/gcc/FreeBSD/include/g++-3"
> 
> Ugh! What's going on here?

I've had the opposite problem (although it's probably due to the same
thing) -- when I compile gcc, I configure it with prefix /usr/local,
but when I install it, it goes into /usr/local/stow/gcc/2.95.2/common
and /usr/local/stow/gcc/2.95.2/i686-pc-linux-gnu separate path (and
then symlinks are put in /usr/local to point at the right files in
those directories).  When /usr/local/bin/g++ runs, I would like it to
use /usr/local/include/g++-3.  Instead, it uses
/usr/local/stow/gcc/2.95.2/i686-pc-linux-gnu/include/g++-3 .. but it
has installed the header files into the common branch rather than the
i686-pc-linux-gnu branch.

So whereas gcc doesn't seem to follow the symlink for you, it follows
it for me (ignoring the compile-time prefix setting) and in both cases
it causes undesired behavior -- and which would both be fixed if the
g++ executable obeyed the prefix setting rather than looking at its
run-time path.

(gcc is not alone in this behavior; I have since given up on trying to
split the architecture-dependent parts from the cross-platform parts
for any package, since the disk space costs less than the hassle.)

-- Michael