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 From: "Kai Henningsen" Organization: Spuentrup CTI To: "Kai Henningsen" , Mumit Khan Date: Tue, 14 Sep 1999 10:45:06 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: Re: GCC CC: "hark sng-" , cygwin AT sourceware DOT cygnus DOT com, Earnie Boyd X-Confirm-Reading-To: "Kai Henningsen" X-pmrqc: 1 In-reply-to: <199909131442.JAA05891@mercury.xraylith.wisc.edu> References: Your message of "Mon, 13 Sep 1999 16:59:28 +0200." X-mailer: Pegasus Mail for Win32 (v3.12a) Message-Id: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-printable to 8bit by delorie.com id EAA30449 On 13 Sep 99, at 9:42, Mumit Khan wrote: > "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 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 AT sourceware DOT cygnus DOT com