Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sourceware.cygnus.com
Message-Id: <199909131442.JAA05891@mercury.xraylith.wisc.edu>
To: "Kai Henningsen" <kai@cats.ms>
cc: "hark sng-" <passhark@hotmail.com>, cygwin@sourceware.cygnus.com,
        Earnie Boyd <earnie_boyd@yahoo.com>
Subject: Re: GCC 
In-Reply-To: Your message of "Mon, 13 Sep 1999 16:59:28 +0200."
             <E11QXZo-0004UX-00@charlotte.intern.cats.ms> 
Date: Mon, 13 Sep 1999 09:42:46 -0500
From: Mumit Khan <khan@xraylith.wisc.EDU>

"Kai Henningsen" <kai@cats.ms> writes:
> On 23 Aug 99, at 11:57, Mumit Khan wrote:
> 
> > "hark sng-" <passhark@hotmail.com> 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 <exec_prefix>/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@sourceware.cygnus.com