----Original Message----
From: Rob Hatcherson
Sent: 17 August 2005 20:49
All,
This issue involves a "File name too long" error being generated by the
C preprocessor that came along with 1.5.18-1. The compiler reports
version 3.4.4, the distro file says 3.4.4-1.
I can #include this header file directly in a .c file with no problem:
#include "C:/d1/d2/d3/d4/...lots more.../blah.h"
The problem occurs if I provide a part of this path via a -I option, and
put the remainder inside quotes in the #include. So say I do this:
gcc -E -I C:/d1/d2/d3/d4 blah.c
...with the source file looking notionally like this:
#include "...lots more.../blah.h"
What I'm wondering is if it's not the concatenation of "C:/d1/d2/d3/d4"
with "...lots more.../blah.h" that is too long, but the concatenation of one
of the _other_ -I search prefix dirs with "...lots more.../blah.h" that
overflows, and then (and this would indeed be a bug in cpp) the preprocessor
gives up after getting an error code, rather than continuing the attempt
with the remaining entries on the search path list.
You could test this theory by attempting the compile that fails again with
the "-v -E" options, just to get the exact command line that is used to
invoke cc1.exe; then rewrite it and try messing with the the -I options so
that your "C:/d1/d2/d3/d4" prefix comes first in the search list, or chop
out all the -I options except your own one and add "-nostdinc"