Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <434D417F.1070500@zedasoft.com> Date: Wed, 12 Oct 2005 12:01:51 -0500 From: Rob Hatcherson User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: Unexpected File Name Too Long Error With #includes References: <4304D450 DOT 2010201 AT zedasoft DOT com> In-Reply-To: <4304D450.2010201@zedasoft.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes All, To recap my original post of 08/17/2005 on this issue, I had a situation where I was trying to #include a fairly long path in a C program. If the full path was given in-line, then the #include succeeded. If part of the path was given in the source, and the prefix was given as a -I option, then the #include failed. I finally figured out what was going on with this and thought I'd share in case it's of interest to anyone (this perhaps is more appropriate for the gcc list(s), but given that Windows is a bit tighter on path lengths - and therefore more likely to produce this problem - it also seemed relevant to the cygwin list). The problem was that the #include was using quotes rather than carets, and cc1 of course made an attempt to resolve the #include relative to the current working directory. In my case the current working directory itself was buried down a deep directory structure such that the working directory's path with the #include path tacked onto the end resulted in a path that exceeded the limit. The simplest example of this problem could be demonstrated by running cc1 directly. cppfiles.c in gcc is where the relevant stuff happens. Ultimately the open_file function is called, which calls open, , and somewhere at the end normalize_posix_path is called from path.cc. normalize_posix_path is where the ENAMETOOLONG errno was coming from. The non-zero errno makes its way back to the stuff in cppfiles.c and ultimately causes the preprocessor to give up. I argued with myself over whether it was reasonable for the preprocessor to bail on this condition. A file #included with quotes will either be found or not. I finally won the argument :-) and concluded that it may not be found because it either doesn't exist or because the path is too long (in which case it can't exist), but either way it doesn't exist and the -I paths should be tried. I don't know what cc1 does on other platforms e.g. Linux if this condition happens. It probably would do the same thing and we just don't see it because the path restrictions are more liberal. FWIW, Rob Rob Hatcherson wrote: > Dave Korn wrote: > >> ----Original Message---- >> >> >>> From: Rob Hatcherson >>> Sent: 17 August 2005 20:49 >>> >> >> >> >> >>> 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 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" >>> >> >> >> >> What I'm wondering is if it's not the concatenation of "C:/d1/d2/d3/d4" >> with "...lots more.../blah.h" that is too long, but the concatenation >> of one >> of the _other_ -I search prefix dirs with "...lots more.../blah.h" that >> overflows, and then (and this would indeed be a bug in cpp) the >> preprocessor >> gives up after getting an error code, rather than continuing the attempt >> with the remaining entries on the search path list. >> >> You could test this theory by attempting the compile that fails >> again with >> the "-v -E" options, just to get the exact command line that is used to >> invoke cc1.exe; then rewrite it and try messing with the the -I >> options so >> that your "C:/d1/d2/d3/d4" prefix comes first in the search list, or >> chop >> out all the -I options except your own one and add "-nostdinc" >> > > This was a great theory, and when I initially read this I thought you > probably had it nailed. But alas, this doesn't seem to be the > problem. Of all the -I options provided, the longest path (which > happens to be the one against which the problematic #include should be > resolved) when cat'd with the #include'd part is still well within the > Windows path length limit, and I can still #include the entire path > verbatim with no problem. > > Unfortunately I had a deadline to meet yesterday and had to resort to > chopping out some path components to get the length down, and also > haven't had time to examine the preprocessor source to see what's > going on. If/when I learn anything I'll chime in again. > > Thanks for the feedback... > > Rob > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Problem reports: http://cygwin.com/problems.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/