Re: Unexpected File Name Too Long Error With #includes

[Rob Hatcherson <rob dot hatcherson at zedasoft dot com>]

Ian Lance Taylor wrote:

> Rob Hatcherson <rob.hatcherson@zedasoft.com> 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