Mail Archives: djgpp/1998/11/02/03:32:05
On Sun, 1 Nov 1998, Eli Zaretskii wrote:
>
> On Sat, 31 Oct 1998, Andris Pavenis wrote:
>
> > djdev202 contains file gxx.exe which looks for libstdcx.a. Unpack
> > file with same name from gpp281b.zip.
> >
> > (One more file in inappropriate place as such file should be located in
> > gppXXXb.zip only)
>
> I rather submit that it was a mistake to put gxx.exe into gppXXXb.zip
> to begin with. I suggested then to call it gpp.exe, to avoid clashes
> with the one in djdev. They are two different programs, and therefore
> they shouldn't be called by the same name. Just think what this mess
> means for the instructions in README.1ST and the FAQ.
>
I still think that only correct place is gppXXXb. Current version
of gxx.exe from djdev201.zip doesn't work more with gcc-2.8.0 and newer.
Only possible problem I see is that gxx.exe from gpp281b.zip and gpp-e11b.zip
doesn't link in libgpp.a by default (that as I think is not so bad).
I think files should belong to binary packages where they naturally belongs:
specs to gcc*b.zip
djgpp.djl - perhaps to binutils (or maybe gcc*b.zip)
gxx.exe - gpp*b.zip
Also:
I think we should change from current hacks to get exceptions
working (crtf.o in gcc-2.8.1 and call to __register_frame_info
from crt0.o in DJGPP 2.02 ) to way used for example in Linux
(2 additional object files crtbegin.o and crtend.o which provide
exceptions handling and not only, so more need to defining
__EH_FRAME_BEGIN and __EH_FRAME_END in djgpp.djl)
I understand there is serious difficulties to change to this from the
approach that were used with gcc-2.7.2.1 and DJGPP 2.01, but I think it is
worth of it as maintainance and upgrade in future should be much easier.
One of ideas here could be making new trees v202 and v202gnu where
these changes would be done. Perhaps it would be made more problems
currently (especially for newbies), but , as I think, much less problems
later.
Andris
- Raw text -