Unexpected File Name Too Long Error With #includes

Unexpected File Name Too Long Error With #includes

[Rob Hatcherson]

Hello,

A few weeks back I ran across an odd behavior of the gcc preprocessor on 
cygwin (gcc reported version 3.4.4-1).  I ping'd the cygwin list first, 
and got one suggestion that ended up not fixing the problem.  I thought 
I'd ping this group on the outside chance somebody here may have 
encountered this problem (the original message I posted to the cygwin 
group follows).

Apologies if this is inappropriate for this list, since this is likely 
an 'ism of something on the cygwin side.  And/or it may have nothing to 
do with the preprocessor directly, but rather be something flakey in an 
underlying lib.

Thanks,

Rob Hatcherson
ZedaSoft, Inc.



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 have a header file whose total path length is 190 characters counting 
drive letters (yeah, I know it's ridiculously long, and I can get around 
this problem by chopping some stuff out, but at the moment I'm wondering 
what I'm missing for future reference).


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"


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.


I've been using Cygwin for a while now and can't recall ever having a 
path length problem unless the length exceeded the total path limit at 
the Windows level (250, or 253, or 255, or whatever it is).  So... this 
makes me wonder if perhaps some feature has been introduced that I'm 
missing, and/or there's some magic option I need to be using.

Has anybody else encountered this behavior?

Sorry if this is a well-known issue.  I've been poking around a bit and 
haven't seen anything relevant (yet).  I'm currently digging in the 
gcc-core source, but thought I'd ping the group in the meantime.

TIA,

Rob Hatcherson
ZedaSoft, Inc.

Re: Unexpected File Name Too Long Error With #includes

[Ian Lance Taylor]

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

Re: Unexpected File Name Too Long Error With #includes

[Rob Hatcherson]

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

Re: Unexpected File Name Too Long Error With #includes

[Ian Lance Taylor]

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.

Otherwise I don't have any suggestions other than running it in the
debugger to see what the actual failing name is.

Ian

Re: Unexpected File Name Too Long Error With #includes

[Rob Hatcherson]

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