Mail Archives: djgpp-workers/1998/03/26/03:50:38
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
- Raw text -