Re: Default gcc for sarge, libunwind
> > Why this library was suddenly deemed critical for the architecture after
> > we were already 3 months into a toolchain freeze is another question.
>
> This I'd like to know, too
>
> > FWIW, these questions seem more appropriate to debian-devel than
> > debian-mentors; these are not what I would call novice packaging
> > questions. :)
>
> When I asked the first question, I expected to turn out to be just a big
> misconception of mine. Well, moving to debian-devel, and Cc-ing Matthieu
> and Al, libunwidn maintainers.
>
Frank,
Libunwind is a stack unwinder. It currently seriously support IA-64
only. However the upstream author is currently working on its extension
over other architecture like i386. It is not only used for debugging
(gdb can use it to unwind stack on a faster way than analysing the
code), but can be used when an exception is raised on a try/catch block
to define which personality routine is used.
More about libunwind:
http://www.hpl.hp.com/research/linux/libunwind/
To learn more about the evolution of the libunwind "functionality" and
the libunwind "package" on Debian/IA-64 please these two threads:
http://lists.debian.org/debian-ia64/2004/11/msg00019.html
and then:
http://lists.debian.org/debian-ia64/2004/12/msg00017.html
The short version of the current issue is:
There were two libunwind. One is used by gcc and is included into gcc
sources. The second one is the one I'm packaging with Al. It contains
more functionality than the gcc one.
However it appeared the gcc "libunwind" was bugged and gcc needed to use
the libunwind provided by our package to work properly.
But the libunwind package is not inside of the base system set and a
depedency on libunwind is not acceptable (freeze).
People are currently working on updating the Debian gcc package to
include the correct libunwind code inside of its own source and not
depend on the libunwind package.
Hoping I'm answering your concern.
Please do not hesitate to ask more,
Matthieu
Reply to: