Date: Mon, 2 Nov 1998 06:32:11 -0200 (WET)
From: Andris Pavenis <pavenis AT lanet DOT lv>
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
cc: djgpp AT delorie DOT com
Subject: Re: djdev202
In-Reply-To: <Pine.SUN.3.91.981101142617.6846a-100000@is>
Message-ID: <Pine.A32.3.91.981102061712.46210A-100000@ieva01.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: djgpp AT delorie DOT com



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