Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
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:	<4304D450.2010201@zedasoft.com>
Date:	Thu, 18 Aug 2005 13:32:48 -0500
From:	Rob Hatcherson <rob DOT hatcherson AT zedasoft DOT com>
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:	<SERRANOjrRZ1UbDBRAr000000fe AT SERRANO DOT CAM DOT ARTIMI DOT COM>
In-Reply-To:	<SERRANOjrRZ1UbDBRAr000000fe@SERRANO.CAM.ARTIMI.COM>
X-IsSubscribed:	yes

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/

- Raw text -