Mail Archives: djgpp/1998/11/02/05:12:20
Date sent: Mon, 2 Nov 1998 11:19:41 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Subject: Re: djdev202
>
> 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.
I understand that it can break some things. But if we are not doing it
we also are making problems which ,as I think , is not less annoying.
(eg. huge amount of questions about problems when upgrading to gcc-2.8.1
and similar ones). Maybe it is worth to have even 2 trees for new and old
versions.
>
> 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?
For example under Linux there is no analogous file (as djgpp.djl for DJGPP).
Ideally it would be enough to have correct default linker scripts in binutils.
However some efforts may be needed to get them working for DJGPP
(maybe, I haven't tested)
>
> > 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?
crtf.o is alien to gcc and egcs (included additionally specially for DJGPP).
crtbegin.o and crtend.o are generated from crtstuff.c which is in standard gcc
(and egcs) source archives. I would prefer a way that doesn't require
additional files to be included. Also when there will be some changes
in exceptions handling they will be supported in crtstuff.c but one will
need to update manually it if standard means will not be used.
Also with these files there is no need for symbls __EH_FRAME_BEGIN
and __EH_FRAME_END in djgpp.djl as the first one should be defined in
crtbegin.o but the second one in crtend.o
Andris
- Raw text -