From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9622 invoked by alias); 4 Oct 2005 22:45:57 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 9612 invoked by uid 22791); 4 Oct 2005 22:45:55 -0000 Received: from [64.207.58.67] (HELO zswww.dmz.zedasoft.com) (64.207.58.67) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 04 Oct 2005 22:45:55 +0000 Received: from [172.16.1.137] ([172.16.1.137]) (authenticated bits=0) by zswww.dmz.zedasoft.com (8.12.8/8.12.8) with ESMTP id j94MjqP8028312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Oct 2005 17:45:53 -0500 Message-ID: <43430620.3080002@zedasoft.com> Date: Tue, 04 Oct 2005 22:45:00 -0000 From: Rob Hatcherson User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Re: Unexpected File Name Too Long Error With #includes References: <4342F356.8010409@zedasoft.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00021.txt.bz2 Ian Lance Taylor wrote: >Rob Hatcherson 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 "" # 1 "" # 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