Ian Lance Taylor wrote:
Rob Hatcherson <rob.hatcherson@xxxxxxxxxxxx> writes:
In my sort-of trivial test case - which is just a file that #include's
the offending file - the command line is this for both the case that
works and the case that doesn't:
g++ -E \
-IC:/WorkAreas/BuildOutput/ZedaSoft/Java/CBA/Domain/Physical/Plugin/Entity/F16/1.4.0/native/include
\
blah.cpp
If the only thing in blah.cpp is this:
#include
"com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h"
Then I get this result:
blah.cpp:3:104:
com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h:
File name too long
# 1 "blah.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "blah.cpp"
Thanks. As far as I can see, this error is happening because the open
system call failed and set errno to some value. When strerror was
called on that value, it returned "File name too long". Presumably
the errno value is ENAMETOOLONG.
You might try running gcc with the -v option to see what the last
directory in the search path is, since it is presumably when using
that directory that ENAMETOOLONG is returned.
I tried that a while back at Dave Korn's suggestion. The spew ended up
looking like this:
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose
--prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc --enable-nls
--without-included-gettext --enable-version-specific-runtime-libs
--without-x --enable-libgcj --disable-java-awt --with-system-zlib
--enable-interpreter --disable-libgcj-debug --enable-threads=posix
--enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions
--enable-hash-synchronization --enable-libstdcxx-debug : (reconfigured)
Thread model: posix
gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
/usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1plus.exe -E -quiet -v
-IC:/WorkAreas/BuildOutput/ZedaSoft/Java/CBA/Domain/Physical/Plugin/Entity/F16/1.4.0/native/include
-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api
blah.cpp -mtune=pentiumpro
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include"
ignoring duplicate directory
"/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
#include "..." search starts here:
#include <...> search starts here:
C:/WorkAreas/BuildOutput/ZedaSoft/Java/CBA/Domain/Physical/Plugin/Entity/F16/1.4.0/native/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/backward
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include
/usr/include
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
End of search list.
blah.cpp:3:104:
com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h:
File name too long
# 1 "blah.cpp"
# 1 "<built-in>"
# 1 "<command line>"
# 1 "blah.cpp"
If one looks in the spew at the list of paths around where it says
"#include "..." search starts here:", we note that the offensive file
path should resolve against the first path in the list, and even when
appended to that path the total path is well within the Windows path
length limit as I understand it (as demonstrated by the fact that I can
#include the full header file path verbatim without issue).
I suppose that last path in the list that has the four ".." in it might
expand to something heinously long, but my assumption is that the
preprocessor will stop searching as soon as the file is found, and it
should resolve it on the first path in the list. Or... perhaps those
"ignored/nonexistent" directories in the spew actually end up getting
tested anyway, and one of those when fully expanded is resulting in a
path that's too long. I don't know my way around the gcc source (yet),
and have been otherwise distracted these last few weeks, so I haven't
had time to sleuth what's going on.
Otherwise I don't have any suggestions other than running it in the
debugger to see what the actual failing name is.
Kewl. Thanks for taking the time to provide some input.
Rob
