Re: does 3.4 truncate include paths?

[Zack Weinberg <zack at codesourcery dot com>]

"sean darcy" <seandarcy@hotmail.com> writes:

> I agree - but what's doing the misquoting. It *does* build with
> gcc-3.3.3.  I've updated to gcc-3.4-20040331.  Same result.
>
> I also checked the environmental variable:
>
> echo $GXX_INCLUDE_PATH
> /usr/lib/gcc/i386-redhat-linux/3.4.0/../../../../include/c++/3.4.0
>
> I don't see how it could be stlport  - how would it even know how to
> truncate and why there? A grep of the entire oo source tree finds no
> "i386-redhat-1".  There are lots of "i386-redhat-linux".

You misunderstand what Dan was saying.  For the sake of brevity, let's
suppose that GXX_INCLUDE_PATH is defined as

#define GXX_INCLUDE_PATH /foo/linux/bar

rather than the much longer definition you were using.  Now, the odds
are that GXX_INCLUDE_PATH is being used something like this:

#define INCLUDE_IN_GXX(filename) _INCLUDE_IN_GXX(GXX_INCLUDE_PATH/filename)
#define _INCLUDE_IN_GXX(pathname) __INCLUDE_IN_GXX(pathname)
#define __INCLUDE_IN_GXX(pathname) #pathname

#include INCLUDE_IN_GXX(ctime)

That's going to be macroexpanded as follows.  I have inserted spaces
between all tokens to emphasize that they are treated as separate
tokens. 

# include _INCLUDE_IN_GXX ( GXX_INCLUDE_PATH / ctime )
# include _INCLUDE_IN_GXX ( / foo / linux / bar / ctime )
# include _INCLUDE_IN_GXX ( / foo / 1 / bar / ctime )       /***/
# include __INCLUDE_IN_GXX ( / foo / 1 / bar / ctime )
# include "/foo/1/bar/ctime"

... at which point expansion is complete, the compiler tries to read
/foo/1/bar/ctime, discovers that it doesn't exist and throws the error
message that has you baffled.

You are probably wondering what on earth happened at the line I marked
with /***/.  Here's a dirty little secret: By default the identifier
"linux" is a predefined macro with expansion "1".  Since we have a
bare token sequence, not a string constant, until the very last stage
of this process, "linux" gets macro-expanded.

String constant concatenation is not done in #include directives,
which is why stlport is doing the above dance with the three layers of
nested macros.  There is no way to do just one level of macro
expansion; it's all or nothing.  Your best bet is probably to use the
-ansi command line switch to suppress the "linux" predefined macro,
but that has other effects which may be undesirable.

zw