Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Date: Thu, 24 Oct 2002 20:55:26 +0200
From: Pavel Tsekov <ptsekov AT gmx DOT net>
X-X-Sender: paveltz AT MORDOR
To: Max Bowsher <maxb AT ukf DOT net>
cc: cygwin AT cygwin DOT com
Subject: Re: [Bug: gcc-3.2-1] Cygwin DLL (CVS HEAD) build failure - gcc uses
 wrong include path order.
In-Reply-To: <00c001c27b7a$2df59150$78d96f83@pomello>
Message-ID: <Pine.CYG.4.44.0210242031250.1428-100000@MORDOR>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Thu, 24 Oct 2002, Max Bowsher wrote:

> I tried to build the Cygwin DLL from CVS, but ran into an error caused by
> gcc inserting an unasked for "-isystem
> /usr/lib/gcc-lib/i686-pc-cygwin/3.2/../../../../include/w32api" into the
> cpp0.exe command line. That path contracts to /usr/include/w32api - so gcc
> uses the installed w32api, not the w32api in the source tree. And, tty.cc is
> using GetConsoleWindow, which hasn't yet appeared in the latest released
> w32api, so it is essential that the one from the source tree be used
> instead.
>
> This seems to be a bug in gcc-3.2-1. gcc2-2.95.3-10 gets further on in the
> compile before hitting an undefined reference to dcgettext__ whilst making
> dumper.exe, which has already been mentioned and diagnosed on list.

I posted some days ago on cygwin-developers about that problem. I didn't
have time to investigate back then and just posted about the problem.
Yesterday I found some time to look into this problem and my finding were
almost the same as yours. There are some additional things I've noted
though, so I'd like to share.

I did some testing with invoking both gcc (C mode) and g++ (C++ mode) with
the -v flag on a simple program having only main () and observed the
system include search paths. /usr/include/w32api appears in the search
path only when compiling in C++ mode. Adding -nostdinc (again in C++ mode)
removes all search paths except /usr/include/w32api. I've also noticed
that -nostdinc++ doesn't affect the search path at all - i know this has
nothing to do with the problem, but thought it's worth mentioning :)

So gcc seems to be OK, but g++ behaves strange.

This is generally not good for people compiling the cygwin sources because
each time the w32api package goes out of sync with the cvs version there
will be similiar problems. For the rest of the cygwin users it is just OK.

There are several easy workarounds for that problem so I don't think this
is such a big problem. Anyway I am curios why /usr/include/w32api is
threated in a special way - you just cant get rid of it ! :)



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/