Message-ID: <00f301c27d5e$6dfefb20$0100a8c0@p4> From: "Andrew Cottrell" To: "Laurynas Biveinis" , "Andris Pavenis" Cc: "DJGPP Workers" References: <50745258354 DOT 20021026221722 AT softhome DOT net> Subject: Re: GPP 3.2 built with 2.04 standard lib header problems Date: Sun, 27 Oct 2002 13:12:53 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Reply-To: djgpp-workers AT delorie DOT com > I've seen this on mailing lists since 3.1, with no apparent solution > (or indication what's broken), and today it hit me: I use gpp32b.zip > from 2.04 site and any C++ program with #include fails to > compile because of missing . I have not seen this before, must have missed it. There have been allot of people not using the latest C++ standard with regards to the "using namespace std;". > I see that binary > distribution of G++ has 3 directories named bits: > lang/cxx/3.2/bits, > lang/cxx/3.2/i586-pc-msdosdjgpp/bits > lang/cxx/3.2/djgpp/bits - note that this one has only header.gcc > containing remaps for only for previous directory! Is this the same as your directory structure? > And all header files mentioned in header.gcc have their original LFN > names, thus they're impossible to use. This setup seems very broken. > After I move headers from .../i586-pc-msdosdjgpp/bits to .../bits, > concat all header.gcc and rename all LFN headers to short names, then > it starts working. > Or is it some big misconfiguration in my installation? Make sure you are using LFN as there are LFN filenames. I have re-built the GCC 3.2 and will upload it in the next few hours, so when you see the 2.04 page change then the files will be ready for download. I upload the files first and then update the html page. Andris, I have had a look at the GCC 3.2 from Simtel and what I built and found the following:- 1) The original GCC 3.2 GPP32b.zip has LFN filenames and as such there may be problems on MS-DOS. 2) I traced the problem with the i586-pc-msdosdjgpp directory to a buggy mv.exe from fileutils (without the rm.exe patch) and it now works with the patched fileutils.