From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32136 invoked by alias); 5 Oct 2005 14:05:44 -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 32127 invoked by uid 22791); 5 Oct 2005 14:05:42 -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; Wed, 05 Oct 2005 14:05:42 +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 j95E5cP8030982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Oct 2005 09:05:40 -0500 Message-ID: <4343DDB2.3020005@zedasoft.com> Date: Wed, 05 Oct 2005 14:05: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> <43430620.3080002@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/msg00026.txt.bz2 Ian Lance Taylor wrote: >Rob Hatcherson 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 "" >># 1 "" >># 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 "" # 1 "" # 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