Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sourceware DOT cygnus DOT com Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com Message-Id: <199909131442.JAA05891@mercury.xraylith.wisc.edu> To: "Kai Henningsen" cc: "hark sng-" , cygwin AT sourceware DOT cygnus DOT com, Earnie Boyd Subject: Re: GCC In-Reply-To: Your message of "Mon, 13 Sep 1999 16:59:28 +0200." Date: Mon, 13 Sep 1999 09:42:46 -0500 From: Mumit Khan "Kai Henningsen" writes: > On 23 Aug 99, at 11:57, Mumit Khan wrote: > > > "hark sng-" writes: > > > I tried compiling a simple program using Ming32 and Cywin GCC, but in = > both i > > > get the CPP program giving me a error message saying: the -remap optio= > n is > > > no understood. > > Same problem here: just calling cpp without any arguments is > enough to make this happen (cpp complains about -remap in a > loop until no more processes). I believe hark sng-'s problem had to do with having GNAT installed, which "hijacks" every other installation via a registry entry. See my "fixes" area for workaround: http://www.xraylith.wisc.edu/~khan/software/gnu-win32/gcc.html#gcc295-fixes My next release of gcc will *ignore* these hidden registry entries to avoid these conflicts. Hopefully GNAT folks will take care and use a more reasonable key next time (vendor specific versioned key perhaps) to avoid this problem. > > Installation sequence: > > 1. B20.1 > 2. Snapshot 19990905 > 3. gcc 2.95 > 4. gcc 2.95 dev-ss > > The weird thing is it looks as if it worked for a short time before > breaking this way. You need to be sure of that if that is indeed the case (that it worked for a short period)! If you don't have GNAT installed, then we obviously need to figure this out. Please look through the output of: $ gcc -print-search-dirs and see where it's looking for things. $ gcc -print-file-name=specs should print the full pathname to the specs files. > > > 1. For cygwin, provide the output of cygcheck: > > > > $ cygcheck -s -r > Thanks. These look good. > > > > 3. compiler version and some runtime info: > > > > $ gcc -v filename.c > > Using builtin specs. Not the "builtin specs". That means GCC is just not finding what it's supposed to. Earnie, the newer versions of gcc provide two different cpp's -- one goes in /bin and other one goes deep into the compiler directory. GCC uses *only* the second one, and the first one is provided for other programs or users who may want to run cpp directly (eg., imake). Regards, Mumit -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com