Mail Archives: djgpp-workers/2001/07/09/13:36:00
On Mon, 9 Jul 2001, Tim Van Holder wrote:
> > When this issue surfaced some time ago, DJ suggested to submit the
> > program for inclusion in the Binutils package, so that it will be always
> > available withe every port of Binutils. But this requires that bfdsymify
> > be portable to platforms other than DJGPP, which is not easy, given the
> > screen capture code. (Btw, do GNU/Linux systems have a device yet that
>
> Well, yes - but you could probably start it out as a DJGPP-only tool (so
> that it only gets built on DJGPP), as there are probably few systems that
> print such a traceback (and for smaller tasks, addr2line suffices).
I don't think it makes full sense to have symify in the binutils --- not
any more than, say, windres, the Windows resource compiler/linker.
But what about submitting it to GDB? It is a kind of debugger, after all.
And GDB comes with bfd, too, so there'd always be one available for
building bfdsymify.
The main drawback then would be that some people would not have installed
GDB, and thus no access to symify. A measure against that could be to
create two binary packages from a single source package --- building
packages from gdb50s would yield gdb50b, holding GDB itself, and sym50b or
some similarly named package, holding bfdsymify. The latter would be put
in the same category as djdev, by the Zip Picker and installation
instructions: 100% necessary whenever compilation is wanted.
> Plus, other systems may dump such a traceback in a redirectable way, so
> extending bfdsymify to be able to read the traceback from a text file would
> be a more useful feature than trying to implement generic screen-reading.
Doesn't bfdsymify do that, already? Plain symify does.
--
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.
- Raw text -