From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2711 invoked by alias); 4 Oct 2005 21:25:47 -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 2697 invoked by uid 22791); 4 Oct 2005 21:25:44 -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 21:25:44 +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 j94LPgP8028128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 4 Oct 2005 16:25:43 -0500 Message-ID: <4342F356.8010409@zedasoft.com> Date: Tue, 04 Oct 2005 21:25:00 -0000 From: Rob Hatcherson User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: gcc-help@gcc.gnu.org Subject: Unexpected File Name Too Long Error With #includes Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-10/txt/msg00019.txt.bz2 Hello, A few weeks back I ran across an odd behavior of the gcc preprocessor on cygwin (gcc reported version 3.4.4-1). I ping'd the cygwin list first, and got one suggestion that ended up not fixing the problem. I thought I'd ping this group on the outside chance somebody here may have encountered this problem (the original message I posted to the cygwin group follows). Apologies if this is inappropriate for this list, since this is likely an 'ism of something on the cygwin side. And/or it may have nothing to do with the preprocessor directly, but rather be something flakey in an underlying lib. Thanks, Rob Hatcherson ZedaSoft, Inc. 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 have a header file whose total path length is 190 characters counting drive letters (yeah, I know it's ridiculously long, and I can get around this problem by chopping some stuff out, but at the moment I'm wondering what I'm missing for future reference). 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" 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. I've been using Cygwin for a while now and can't recall ever having a path length problem unless the length exceeded the total path limit at the Windows level (250, or 253, or 255, or whatever it is). So... this makes me wonder if perhaps some feature has been introduced that I'm missing, and/or there's some magic option I need to be using. Has anybody else encountered this behavior? Sorry if this is a well-known issue. I've been poking around a bit and haven't seen anything relevant (yet). I'm currently digging in the gcc-core source, but thought I'd ping the group in the meantime. TIA, Rob Hatcherson ZedaSoft, Inc.