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 Date: Thu, 24 Oct 2002 20:55:26 +0200 From: Pavel Tsekov X-X-Sender: paveltz AT MORDOR To: Max Bowsher 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: 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/