Date: Thu, 26 Mar 1998 10:43:07 +0200 (EET) From: Andris Pavenis To: Robert Hoehne cc: djgpp-workers AT delorie DOT com Subject: Re: gcc 2.8.1 In-Reply-To: <351963F5.1CB3A690@gmx.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 25 Mar 1998, Robert Hoehne wrote: > Andris Pavenis wrote : > > > > Are You interested to test version of gcc-2.8.1 for DJGPP. > > I put source archive in > > http://www.lanet.lv/~pavenis/gcc281s.zip > > Thanks for pointing me to this. I got and built it sucsessfully. > > Are you planning to make the official DJGPP archives for > gcc 2.8.1? If yes, this would be good, but I would recommend > in this case also to include the fixes so that the exception > support on DJGPP will work. I think, that you have read my > posts to this in djgpp-workers. If not, let me know and I will > send you my ideas for fixing it. I have read them but havent tried them yet. Does it mean that it is necessary to include additional startup file and updated specs file in binary distribution? Is it necessary to apply these changes before building gcc? It is still necessary to change source archive due to problem with missing definition of MKTEMP_EACH_FILE in gcc.c (I transfered changes from 2.8.0 to 2.8.1 together with such bugs of course) as it perhaps can be easily done. It also should be nice to solve another problem with temporary files (possible conflicts between copies of gcc running simultanously in some multitasking system) however this can be done later (maybe in stable release) I see three possible ways: - using some artificially created PID to generate name. I don't believe this will be reliable (there were discussions about this way recently); - creating directory with unique name under %TMPDIR and after that creating temporary files in this directory. Before quitting we should delete this directory of course - using %TMPDIR only. Then perhaps we should create file immediatelly from gcc.exe when allocating name of temporary file (repeating with another name if file already exist) to avoid race conditions in multitasking systems such as Windows (if we generate name of some non existing file and only transfer the name os parameter to cc1 or something like there is still possible for other process to choose the same name. So we can still get conflicts) One more problem with distribution is libg++. libg++-2.8.1 appeared in ftp.gnu.org some weeks ago but was soon removed as being corrupt. Some archive libg++-2.8.0.tar.gz appeared later but it is exact copy of version from January. There is notes in gnu.g++.bugs that we should wait 2.8.1.1 or something similar. Perhaps we should still use 2.8.0. (I built some mix of 2.8.0 and 2.8.1, librx and somthing more was missing in 2.8.1. I only think that such version should not be released) One more problem is that perhaps IT WILL BE NECESSARY to rebuild even libstdc++ and libg++ when changing to gcc-2.8.1 due to changes in use of some external symbols in 2.8.0 only (there is no such problem in gcc-2.7.2.1, gcc-2.8.1 and pgcc-2.90.23). One can see this problem when using class ostrstream. If I'm linking program build with 2.8.1 with the library built with 2.8.0 then we'll get error messages about missing ostrstream::~ostrstream(void). Looks that gcc-2.7.2.1, gcc-2.8.1 and pgc-2.90.23 are compatible from this point of view. Andris Pavenis