Message-Id: <200008091602.MAA14011@delorie.com> Date: Wed, 09 Aug 2000 19:05:35 +0200 To: house AT usq DOT edu DOT au X-Mailer: Emacs 20.6 (via feedmail 8.2.emacs20_6 I) and Blat ver 1.8.5b From: "Eli Zaretskii" CC: djgpp AT delorie DOT com In-reply-to: <3990BD39.7A990D1E@usq.edu.au> (message from Ron House on Wed, 09 Aug 2000 02:08:57 +0000) Subject: Re: A few glitches. Was: STL under DJGPP? References: <398FBB27 DOT 672BE8D9 AT usq DOT edu DOT au> <3990BD39 DOT 7A990D1E AT usq DOT edu DOT au> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: Ron House > Newsgroups: comp.os.msdos.djgpp > Date: Wed, 09 Aug 2000 02:08:57 +0000 > > I have been following the instructions given to upgrade my compiler. I > deleted the list of files given in the readme file (cc1.exe etc) - > although these weren't in the directories stated, they were in > lib/gcc-lib/djgpp/2.81. > > I unpacked lgp2952b.zip, gcc2952b.zip, gpp2952b.zip, and djcrx203.zip. > > Then I had the following dialog. (sdir is a program of mine to locate > files.): > > -------------------------------------------------- > c:\tmp>gxx t.cpp > gxx.exe: installation problem, cannot exec `cc1plus': No such file or > directory (ENOENT) Remove gxx.exe as well. Then use gpp.exe (which comes with gpp2952b.zip) instead. Your gxx.exe is from the v2.8.1 distribution, so it looks for cc1plus.exe in the lib/gcc-lib/djgpp/2.81, instead of in lib/gcc-lib/djgpp/2.952. The rule is: remove ALL the files that belong to the old version. Section 4.7 of the DJGPP FAQ list shows one way of doing that efficiently. If the above still doesn't help, say "gpp -v t.cpp" and post here everything that the compiler prints. (You might look into that output first, as it should give a clue as to what's happening.) > As you can see, the files are there, but in a "2.952" directory that > isn't being 'seen'. I found and inspected a file called djgpp.env, but > nothing in it seems to refer to the old "2.81" directory, which was > seen, so I am somewhat baffled. The 2.81 thing is hardwired into the compiler binary, because that's how it was configured when it was built. Since gxx.exe is from an old distribution, it still wants to find its subprograms and libraries in that place. That's why it fails.