From: Rob Hatcherson <rob.hatcherson@zedasoft.com>
To: gcc-help@gcc.gnu.org
Subject: Re: Unexpected File Name Too Long Error With #includes
Date: Tue, 04 Oct 2005 22:45:00 -0000 [thread overview]
Message-ID: <43430620.3080002@zedasoft.com> (raw)
In-Reply-To: <m3hdbx9den.fsf@gossamer.airs.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
next prev parent reply other threads:[~2005-10-04 22:45 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 [this message]
2005-10-05 3:20 ` Ian Lance Taylor
2005-10-05 14:05 ` Rob Hatcherson
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=43430620.3080002@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).