From: Rob Hatcherson <rob.hatcherson@zedasoft.com>
To: gcc-help@gcc.gnu.org
Subject: Re: Unexpected File Name Too Long Error With #includes
Date: Wed, 05 Oct 2005 14:05:00 -0000 [thread overview]
Message-ID: <4343DDB2.3020005@zedasoft.com> (raw)
In-Reply-To: <m364scabvl.fsf@gossamer.airs.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
prev parent reply other threads:[~2005-10-05 14:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-04 21:25 Rob Hatcherson
2005-10-04 21:32 ` Ian Lance Taylor
2005-10-04 22:45 ` Rob Hatcherson
2005-10-05 3:20 ` Ian Lance Taylor
2005-10-05 14:05 ` Rob Hatcherson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4343DDB2.3020005@zedasoft.com \
--to=rob.hatcherson@zedasoft.com \
--cc=gcc-help@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).