From: Andris Pavenis <pavenis AT latnet DOT lv>
To: djgpp-workers AT delorie DOT com, sandmann AT clio DOT rice DOT edu (Charles Sandmann)
Subject: Re: BNU 2.13.2.1 query
Date: Mon, 10 Feb 2003 09:47:25 +0200
User-Agent: KMail/1.5
Cc: djgpp-workers AT delorie DOT com
References: <10302072150 DOT AA14657 AT clio DOT rice DOT edu>
In-Reply-To: <10302072150.AA14657@clio.rice.edu>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200302100947.25391.pavenis@latnet.lv>
Reply-To: djgpp-workers AT delorie DOT com

On Friday 07 February 2003 23:50, Charles Sandmann wrote:
> > > Unless it fixes working with UPX, or someone understands why these
> > > changes are happening - I think we should just say NO to newer binutils
> > > and stick with something older that works.  But that's up to whoever is
> > > using it :-)
> >
> > Often we find time to look into deeper details only when something stops
> > to work. Unfortunatelly it's so. But we all have also many other things
> > to do.
>
> Sure, but when we find something does break, we should stop using it
> until we understand why.

I'm only afraid, that struct following such rule will cause us sticking with 
old versions forever due to limited amount of time we can spend for DJGPP.

I'm not talking about critical breakages when for example GCC doesn't build
or it's unusable at all (eg. not able to compile sources of some supported 
languages, or something else is broken seriously enough). I didn't saw (also 
don't remember having seen them reported) any v2load related failures as 
v2load is used for debugging support.

Also see later message from Laszlo about real reason of UPX problems

> So I don't believe the newer binutils should be recommended by the
> zip picker (or outside an alpha/beta directory on Simtel) until
> we understand it.  If we find a problem after we've moved it to
> release - we should roll back to last known good.
>
> I do believe we should continue to build the newer versions and
> use the newer versions (performance and size not an issue) if
> something isn't broken.  I do appreciate the effort put into
> building the newer versions.

Any version will have bugs. So we'll be able to find broken things. So 
only way how to surely not to run into something broken is not to use 
it at all. I think one should decide, whether some known breakage is serious 
enough to step back or we can leave it in for some tine.

Another example. 

There are things with C++ iostreams classes were we have
regressions against gcc-2.95.X. It is support of text mode I/O in DJGPP. With 
gcc-2.95.X seekp and tellg memebers of fstream classes worked for files opened 
in text mode. Unfortunately it's no more works with libstdc++-v3. I don't 
think it can be fixed without serious reworking libstdc++-v3. I don't have 
time for that. Also really critical bug I made patching std::fstream in DJGPP 
port of gcc-3.0.2 (needed to support something for text mode I/O at all) 
stayed unnoticed for several month. Somebody reported it only after I myself 
had found it and fixed.

Also C++ ABI has changed, so we have incompatibilities betwwen object files
compiled with different GCC versions.

Andris