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:
>
>  
>
> > 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"
> >
> >
> > By experimentation (with this particular file I'm having problems
> > with, so this isn't a general observation) when the total length of
> > the stuff inside the quotes in the #include statement reaches 82
> > characters in length I get a "File name too long" error from the
> > preprocessor.  Yet as noted earlier I can include the entire path
> > inline without a complaint.
> >    
>
> What is the exact command line, and what is the exact error message?
>
> Ian
>  

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"


If the only thing in blah.cpp is this:

#include 
"C:/WorkAreas/BuildOutput/ZedaSoft/Java/CBA/Domain/Physical/Plugin/Entity/F16/1.4.0/native/include/com/zedasoft/cba/plugin/entity/platform/air/fighter/f16/view/cockpit/hud/f16hudcore/F16Hud.h"

...then everything works.


A guy named Dave Korn on the cygwin mailing list suggested that perhaps 
the partial path name, when appended onto one of the implicit -I paths, 
e.g. the ones the system provides, might be the thing that was too long 
rather than the final resolved path.  I thought this was a great theory, 
but in the end it ended up not being the case because the path against 
which the header would be resolved (i.e. the path given above) was the 
longest of all the preprocessor would have potentially tried.

This smells like a bug to me, but who knows.  It was working on a prior 
cygwin release; I'd have to do some digging to see what version of gcc 
that was.

Rob