Date:	Mon, 2 Nov 1998 11:19:41 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Andris Pavenis <pavenis AT lanet DOT lv>
cc:	djgpp AT delorie DOT com
Subject:	Re: djdev202
In-Reply-To:	<Pine.A32.3.91.981102061712.46210A-100000@ieva01.lanet.lv>
Message-ID:	<Pine.SUN.3.91.981102111051.11545A-100000@is>
MIME-Version:	1.0
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?

- Raw text -