public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Kai Henningsen" <kai AT cats.ms>
To: "Kai Henningsen" <kai AT cats.ms>,
	Mumit Khan <khan AT xraylith.wisc.EDU>
Cc: "hark sng-" <passhark AT hotmail.com>,
	cygwin AT sourceware.cygnus.com,
	Earnie Boyd <earnie_boyd AT yahoo.com>
Subject: Re: GCC
Date: Tue, 14 Sep 1999 01:54:00 -0000	[thread overview]
Message-ID: <E11QoD4-0006k0-00@charlotte.intern.cats.ms> (raw)
In-Reply-To: <199909131442.JAA05891@mercury.xraylith.wisc.edu>

On 13 Sep 99, at 9:42, Mumit Khan wrote:

> "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

Well, I don't have (and never had) GNAT installed. And I don't have
the registry keys mentioned there.

> > 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)!

Well, I was trying to build the tiff libs. After finding that the
config.guess needed to be updated, that configure was highly
confused by ash refusing to do a cd, it suddenly told me there was
no working C compiler available. However, I had already removed
left-over a.exe files several times (back then, the problem was it
was looking for a.out)!

*** UPDATE *** before pondering the following info, read the rest of
the message for interesting changes!

> 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

bash-2.02$ gcc -print-search-dirs
install: /Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/
programs: /cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/
2.95/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/:/Cygnus/cygwin-b2
0/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygw
in32/lib/gcc-lib/i586-cygwin32/:/usr/lib/gcc/i586-cygwin32/2.95/:/usr/lib/gcc/i5
86-cygwin32/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin
32/2.95/../../../../i586-cygwin32/bin/i586-cygwin32/2.95/:/cygdrive/f/cygnus/CYG
WIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/b
in/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../.
./i586-cygwin32/bin/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/g
cc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/bin/
libraries: /cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32
/2.95/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/:/Cygnus/cygwin-b
20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/usr/lib/gcc/i586-cygwin32/2.
95/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/.
./../../../i586-cygwin32/lib/i586-cygwin32/2.95/:/cygdrive/f/cygnus/CYGWIN~1/H-I
586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib/:/Cygn
us/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cy
gwin32/lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i5
86-cygwin32/2.95/../../../../i586-cygwin32/lib/:/cygdrive/f/cygnus/CYGWIN~1/H-I5
86~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../i586-cygwin32/2.95/:/cygdriv
e/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../:/Cy
gnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../i586-cyg
win32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/..
/../../:/lib/i586-cygwin32/2.95/:/lib/:/usr/lib/i586-cygwin32/2.95/:/usr/lib/
bash-2.02$

> and see where it's looking for things.
>
>   $ gcc -print-file-name=specs

bash-2.02$ gcc -print-file-name=specs
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/specs

bash-2.02$

> > >   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.

Hmm. Thinking about it, one of the things I think I did shortly before
the problem was adding /bin in front of the path, which points here:

bash-2.02$ mount
Device              Directory           Type         Flags
f:\cygnus\cygwin-b20\H-i586-cygwin32\bin  /bin                user         binmo
de
e:                  /                   user         binmode
bash-2.02$

And the cpp crash I looked most into was just typing "cpp" at the
bash prompt.

Let's just see ...

... oops. cpp doesn't crash right now! What the ...?

Oh, of course, /bin is missing. See if that breaks it - yup, sure does!

So, here is the above info again with the new PATH:

bash-2.02$ gcc -print-search-dirs
install: /Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/
programs: /bin/../lib/gcc-lib/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/:/Cygnus/c
ygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i
586-cygwin32/lib/gcc-lib/i586-cygwin32/:/usr/lib/gcc/i586-cygwin32/2.95/:/usr/li
b/gcc/i586-cygwin32/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cyg
win32/bin/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../..
/i586-cygwin32/bin/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32
/2.95/../../../../i586-cygwin32/bin/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i58
6-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/bin/
libraries: /bin/../lib/gcc-lib/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/:/Cygnus/
cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/usr/lib/gcc/i586-cyg
win32/2.95/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib
/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cyg
win32/lib/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../
../../../i586-cygwin32/lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin3
2/lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib/:/bin/../lib/gcc-
lib/i586-cygwin32/2.95/../../../i586-cygwin32/2.95/:/bin/../lib/gcc-lib/i586-cyg
win32/2.95/../../../:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin3
2/2.95/../../../i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-l
ib/i586-cygwin32/2.95/../../../:/lib/i586-cygwin32/2.95/:/lib/:/usr/lib/i586-cyg
win32/2.95/:/usr/lib/
bash-2.02$


bash-2.02$ gcc -print-file-name=specs
specs
bash-2.02$

So I guess that's it, but what happens here? Surely gcc should not
break from changing PATH?!

Ah yes, I remember why I did that:

/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct

Of course, the subdir is just there. :-(

A short test (without /bin, but it turns out this doesn't change
anything):

bash-2.02$ cd libtiff
bash-2.02$ pwd
/tiffdir/libtiff
bash-2.02$ cd -
/tiffdir
bash-2.02$ $SHELL -c "cd libtiff"
/bin/sh: cd: libtiff: No such file or directory
bash-2.02$ $SHELL
sh-2.02$ pwd
/tiffdir
sh-2.02$ cd libtiff
sh: cd: libtiff: No such file or directory
sh-2.02$ exit
bash-2.02$ $SHELL --version
GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32)
Copyright 1998 Free Software Foundation, Inc.
bash-2.02$

What's happening?! This is like nothing I have ever seen!


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

WARNING: multiple messages have this Message-ID
From: "Kai Henningsen" <kai@cats.ms>
To: "Kai Henningsen" <kai@cats.ms>, Mumit Khan <khan@xraylith.wisc.EDU>
Cc: "hark sng-" <passhark@hotmail.com>,
	cygwin@sourceware.cygnus.com, Earnie Boyd <earnie_boyd@yahoo.com>
Subject: Re: GCC
Date: Thu, 30 Sep 1999 23:42:00 -0000	[thread overview]
Message-ID: <E11QoD4-0006k0-00@charlotte.intern.cats.ms> (raw)
Message-ID: <19990930234200.3t3T7zWf3j230T4U8wHFuXiIBwIt7OW56-tcBfW08qA@z> (raw)
In-Reply-To: <199909131442.JAA05891@mercury.xraylith.wisc.edu>

On 13 Sep 99, at 9:42, Mumit Khan wrote:

> "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

Well, I don't have (and never had) GNAT installed. And I don't have
the registry keys mentioned there.

> > 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)!

Well, I was trying to build the tiff libs. After finding that the
config.guess needed to be updated, that configure was highly
confused by ash refusing to do a cd, it suddenly told me there was
no working C compiler available. However, I had already removed
left-over a.exe files several times (back then, the problem was it
was looking for a.out)!

*** UPDATE *** before pondering the following info, read the rest of
the message for interesting changes!

> 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

bash-2.02$ gcc -print-search-dirs
install: /Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/
programs: /cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/
2.95/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/:/Cygnus/cygwin-b2
0/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygw
in32/lib/gcc-lib/i586-cygwin32/:/usr/lib/gcc/i586-cygwin32/2.95/:/usr/lib/gcc/i5
86-cygwin32/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin
32/2.95/../../../../i586-cygwin32/bin/i586-cygwin32/2.95/:/cygdrive/f/cygnus/CYG
WIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/b
in/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../.
./i586-cygwin32/bin/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/g
cc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/bin/
libraries: /cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32
/2.95/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/:/Cygnus/cygwin-b
20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/usr/lib/gcc/i586-cygwin32/2.
95/:/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/.
./../../../i586-cygwin32/lib/i586-cygwin32/2.95/:/cygdrive/f/cygnus/CYGWIN~1/H-I
586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib/:/Cygn
us/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cy
gwin32/lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i5
86-cygwin32/2.95/../../../../i586-cygwin32/lib/:/cygdrive/f/cygnus/CYGWIN~1/H-I5
86~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../i586-cygwin32/2.95/:/cygdriv
e/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../:/Cy
gnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../i586-cyg
win32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/..
/../../:/lib/i586-cygwin32/2.95/:/lib/:/usr/lib/i586-cygwin32/2.95/:/usr/lib/
bash-2.02$

> and see where it's looking for things.
>
>   $ gcc -print-file-name=specs

bash-2.02$ gcc -print-file-name=specs
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/../lib/gcc-lib/i586-cygwin32/2.95/specs

bash-2.02$

> > >   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.

Hmm. Thinking about it, one of the things I think I did shortly before
the problem was adding /bin in front of the path, which points here:

bash-2.02$ mount
Device              Directory           Type         Flags
f:\cygnus\cygwin-b20\H-i586-cygwin32\bin  /bin                user         binmo
de
e:                  /                   user         binmode
bash-2.02$

And the cpp crash I looked most into was just typing "cpp" at the
bash prompt.

Let's just see ...

... oops. cpp doesn't crash right now! What the ...?

Oh, of course, /bin is missing. See if that breaks it - yup, sure does!

So, here is the above info again with the new PATH:

bash-2.02$ gcc -print-search-dirs
install: /Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/
programs: /bin/../lib/gcc-lib/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/:/Cygnus/c
ygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i
586-cygwin32/lib/gcc-lib/i586-cygwin32/:/usr/lib/gcc/i586-cygwin32/2.95/:/usr/li
b/gcc/i586-cygwin32/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cyg
win32/bin/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../..
/i586-cygwin32/bin/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32
/2.95/../../../../i586-cygwin32/bin/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i58
6-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/bin/
libraries: /bin/../lib/gcc-lib/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/:/Cygnus/
cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/:/usr/lib/gcc/i586-cyg
win32/2.95/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib
/i586-cygwin32/2.95/:/bin/../lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cyg
win32/lib/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin32/2.95/../
../../../i586-cygwin32/lib/i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin3
2/lib/gcc-lib/i586-cygwin32/2.95/../../../../i586-cygwin32/lib/:/bin/../lib/gcc-
lib/i586-cygwin32/2.95/../../../i586-cygwin32/2.95/:/bin/../lib/gcc-lib/i586-cyg
win32/2.95/../../../:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-lib/i586-cygwin3
2/2.95/../../../i586-cygwin32/2.95/:/Cygnus/cygwin-b20/H-i586-cygwin32/lib/gcc-l
ib/i586-cygwin32/2.95/../../../:/lib/i586-cygwin32/2.95/:/lib/:/usr/lib/i586-cyg
win32/2.95/:/usr/lib/
bash-2.02$


bash-2.02$ gcc -print-file-name=specs
specs
bash-2.02$

So I guess that's it, but what happens here? Surely gcc should not
break from changing PATH?!

Ah yes, I remember why I did that:

/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct
ory
= libtiff
/cygdrive/f/cygnus/CYGWIN~1/H-I586~1/bin/sh: cd: libtiff: No such file or direct

Of course, the subdir is just there. :-(

A short test (without /bin, but it turns out this doesn't change
anything):

bash-2.02$ cd libtiff
bash-2.02$ pwd
/tiffdir/libtiff
bash-2.02$ cd -
/tiffdir
bash-2.02$ $SHELL -c "cd libtiff"
/bin/sh: cd: libtiff: No such file or directory
bash-2.02$ $SHELL
sh-2.02$ pwd
/tiffdir
sh-2.02$ cd libtiff
sh: cd: libtiff: No such file or directory
sh-2.02$ exit
bash-2.02$ $SHELL --version
GNU bash, version 2.02.1(2)-release (i586-pc-cygwin32)
Copyright 1998 Free Software Foundation, Inc.
bash-2.02$

What's happening?! This is like nothing I have ever seen!


Regards - Kai Henningsen

--
http://www.cats.ms
Spuentrup CTI       Fon: +49 251 322311 0
Windbreede 12       Fax: +49 251 322311 99
D-48157 Münster     Mob: +49 161 3223111
Germany             GSM: +49 171 7755060

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

  reply	other threads:[~1999-09-14  1:54 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-08-23  8:50 GCC hark sng-
1999-08-23  9:59 ` GCC Mumit Khan
1999-08-31 23:49   ` GCC Mumit Khan
1999-09-13  8:01   ` GCC Kai Henningsen
1999-09-13  8:54     ` GCC Mumit Khan
1999-09-14  1:54       ` Kai Henningsen [this message]
1999-09-14  9:41         ` GCC Mumit Khan
1999-09-30 23:42           ` GCC Mumit Khan
1999-09-30 23:42         ` GCC Kai Henningsen
1999-09-30 23:42       ` GCC Mumit Khan
1999-09-30 23:42     ` GCC Kai Henningsen
1999-08-31 23:49 ` GCC hark sng-
  -- strict thread matches above, loose matches on Subject: below --
2008-08-18 11:56 GCC John Emmas
2008-08-18 12:11 ` GCC Hugh Sasse
2008-08-18 12:20   ` GCC John Emmas
2002-05-25  9:46 gcc hongxun lee
2002-01-02  9:14 gcc Givon Zirkind
2002-01-03 16:21 ` gcc Tim Prince
2001-05-07 17:49 gcc Bryan Higgins
2001-05-08  6:00 ` gcc Earnie Boyd
2001-03-31 11:06 gcc John Weeks
2001-03-31 13:06 ` gcc Christopher Faylor
2001-03-31 14:14   ` gcc John Weeks
2001-03-31 14:24     ` gcc Christopher Faylor
2000-11-09 11:01 GCC Earnie Boyd
2000-11-09  7:19 GCC Schaible, Joerg
2000-11-09  7:13 GCC Milan Stanojevic
2000-11-09  7:19 ` GCC Cal Erickson
2000-11-09 10:45   ` GCC Milan Stanojevic
1999-09-14  5:48 GCC Earnie Boyd
1999-09-14  6:54 ` GCC Kai Henningsen
1999-09-30 23:42   ` GCC Kai Henningsen
1999-09-30 23:42 ` GCC Earnie Boyd
1999-09-13  8:16 GCC Earnie Boyd
1999-09-14  2:00 ` GCC Kai Henningsen
1999-09-14  9:56   ` GCC Michael V. Nikolaev
1999-09-30 23:42     ` GCC Michael V. Nikolaev
1999-09-30 23:42   ` GCC Kai Henningsen
1999-09-30 23:42 ` GCC Earnie Boyd
1998-11-29 10:34 Gcc Haynes, Dan
1998-11-29  1:32 Gcc Holger Burkarth
1998-11-03 13:49 gcc marc_auslander
1998-07-08 10:01 GCC Earnie Boyd
1998-07-03 16:33 GCC Bruno da Rocha
1997-12-05  6:13 gcc Mark Young (in6)
1997-10-16 20:09 GCC Earnie Boyd
1997-10-15 17:59 GCC David Vang
1997-10-08  2:57 gcc Brad Haack
1997-09-24  2:09 gcc nazg
1997-09-23 13:38 gcc Earnie Boyd
1997-09-22  9:29 gcc Earnie Boyd
1997-09-22  6:23 gcc nazg
1997-09-20  0:35 gcc young lee

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E11QoD4-0006k0-00@charlotte.intern.cats.ms \
    --to=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).