Re: libunwind in unstable
Ian Wienand writes:
> On Mon, Nov 22, 2004 at 05:30:38PM -0800, David Mosberger wrote:
> > That would make sense. libstdc++5 calls _Unwind_Resume() which
> > is/should be implemented by libunwind.so.7. With older versions of
> > GCC, it was implemented as part of libgcc_eh.a/libgcc_s.so.
>
> Actually, when I checked with ldd I forgot it is recursive, if you
> actually look at the DT_NEEDED flags the dependency comes from
> /lib/libgcc_s.so.1
>
> As I understand it the problem stems from the fact that the libgcc1
> package actually comes from gcc-3.4 (to satisify something or other).
yes, I missed the fact, that libgcc1 built by 3.4.3 introduces this
dependency despite having libunwind7-dev not installed.
> Poking around gcc-3.4 I think this is caused by PR14925, for which the
> fix appeared in the 3.4.3 release, which was built by the autobuilder
> on the 20th Nov 2004. This (AFAICS) creates a "dummy" libunwind.so.7
> in the case where the Mosberger (or other) libunwind isn't found.
>
> I'm no gcc packaging expert, but I applied the attached patch to
> gcc-3.4 and at least got libunwind into libgcc1
>
> ianw@baci:/usr/src/tmp/glibc-debian$ dpkg --contents ./libgcc1_3.4.3-1_ia64.deb
> [blah]
> -rw-r--r-- root/root 48752 2004-11-23 16:04:31 ./lib/libgcc_s.so.1
> -rw-r--r-- root/root 49904 2004-11-23 16:04:31 ./lib/libunwind.so.7
>
> Of course, this means that if you install libunwind7, which lives in
> /usr/lib/, /lib gets searched first and the Mosberger libunwind isn't
> found. You can't put it in /usr/lib/ because it will conflict with
> the libunwind package. So in my fairly uneducated opinion we could
> either
>
> - write a patch similar to attached so libgcc1 includes libunwind.so,
> but setup some sort of alternatives system where the libunwind7
> package can override.
>
> - fix the gcc build to depend on libunwind for ia64 and always use
> the Mosberger libunwind. I see there is already a
> control.m4.unwind' but it doesn't appear to be used? I think this
> has implications for stable which is frozen, too.
We currently cannot include libunwind7 as a required package, as
libgcc1 is at the moment. So we only have the first option.
- include the /lib/libunwind.so.7.0.0 in the libgcc1 package, as built
by gcc-3.4. The libunwind-0.98.3 package introduces a new
/usr/lib/libunwind-ia64.so.7.0.0, which is not build by gcc-3.4.
What to do with this library?
- To libunwind7, add a conflict to libgcc1 (= 1:3.4.3-1), either build
a new libunwind7 without the shared lib and depend on libgcc1 (>=
1:3.4.3-2) or dpkg-divert the shared lib (but I've never seen
diversions of shared libs before).
- For gcc-3.4, add a build dependency on libunwind7-dev.
Is the patch in #278836 a prerequisite for the above changes, or can
it be done without it? Same question for #278837.
As an alternative, revert the libunwind patch. There should be no
direct references to it, so if libgcc1 is built without this
dependency, it should be gone for most packages.
Please let's sort out things and then confess the mess to the release
managers...
Matthias
Reply to: