From: pavenis AT lanet DOT lv To: "Mark E." , djgpp-workers AT delorie DOT com Date: Mon, 26 Jun 2000 18:53:51 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ANNOUNCE: Binutils 2.10 released Message-ID: <3957A6BF.21214.FB023@localhost> In-reply-to: <395740E3.23821.4C853B@localhost> References: <39577D84 DOT 22597 DOT 95F1E8 AT localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On 26 Jun 2000, at 11:39, Mark E. wrote: > > > On a rather disturbing note, I discovered late last night some C++ programs > > > crash when built under 2.10, but C programs run fine. I think I know what > > > needs to be fixed, but when I do fix it I'll have to re-upload Binutils 2.10 > > > (sorry). > > > > > > > I haven't noticed such behaviour with C++ and binutils-2.10 (I'm not > > using "official" bnu210b.zip though but my own binaries I built using > > cross-compiling under Linux). > > mkdoc.cc in DJGPP CVS crashes when run when compiled with bnu210b.zip. I did some tests with 22 June CVS version of DJGPP. I have newer one unpacked on Linux partition (updated nigthly from cron task), but I didn't want to reboot ... Strange. All my attempts to break mkdoc.cc I tried failed: 1. normal build in DOS session under Win98 SE with my binaries of binutils-2.10 2. the same with bnu210b.zip from DJGPP distribution (DOS session under Win98 SE) 3. the same with bnu210b.zip from DJGPP distribution under plain DOS 4. the same as 2 but I only removed -mbnu210 from cc1spec No crashes from mkdoc.exe at all (In other attemps except the first one I simply removed hostbin/makedoc.exe and rerun make) Installed DJGPP version was the same as I built (22 June CVS) If Your problems with mkdoc.exe reproducible? Andris > > I also want to update the documentation to mention that the refreshed > Fileutils 3.16 (year 2000 timestamp) is required or else documentation > generation may go wrong (the problem is with 'ln -s' as usual). > > Mark >