Date: Mon, 2 Nov 1998 11:19:41 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Andris Pavenis cc: djgpp AT delorie DOT com Subject: Re: djdev202 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On Mon, 2 Nov 1998, Andris Pavenis wrote: > 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 The issue here is not the principles (with which I agree), but practical problems that could be the result of these changes. For example, removing the functionality of gxx from djdev might break some package which links in libgpp.a and relies on gxx to do that automatically. We already talked about specs in another thread (the problem with __DJGPP__ symbol that it defines). That's another example of how removing files could introduce subtle bugs. As for djgpp.djl, it ``belongs'' to both GCC and Binutils. Where should we put it, and how will we handle the possible conflicts when future versions of Binutils are released? GCC has its private place which depends on its version, but what about Binutils? > 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) What are the advantages of the Linux method, and why crtf.o is more ``hack'' than crtbegin.o and crtend.o?