Bug#284563: libunwind in unstable
H. J. Lu writes: > On Thu, Dec 09, 2004 at 12:49:38PM +0100, Matthias Klose wrote: > > H. J. Lu writes: > > > On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote: > > > > > On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL > > > > > PROTECTED]> said: > > > > > > > > Matthias> glibc now fails to build from source: > > > > > > > > Matthias> undefined reference to `__gcc_personality_v0' > > > > > > > > Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. > > > > > > > > I cc'd HJ Lu since he may remember better what the final conclusion > > > > was in regards to the personality routine. IIRC, the resolution was > > > > that it needs to be provided by libgcc. > > > > > > We decided that the personality routine shouldn't be the part of > > > libunwind.so. For gcc 3.4/4.0, unwind-sjlj.c and unwind-c.c are > > > in libgcc_eh.a, unwind-sjlj.c, unwind-c.c, unwind-compat.c and > > > unwind-dw2-fde-compat.c are in libgcc_s.so.1. > > > > ok, I'm currently bootstrapping gcc-3.3 with the patch attached, a > > glibc bootstrap using this compiler did succeed. I'll upload the fixed > > gcc-3.3, when bootstrap and testsuite finishes. > > > > Why not just backport the 3.4 libunwind patches to 3.3? attached. works for me. I'd like to get some feedback from ia64 users/developers, as I don't use ia64 that much. Matthias gcc33.tgz Description: Binary data
Bug#284563: libunwind in unstable
> On Thu, 9 Dec 2004 13:35:07 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> works ok until building glibc with the just built Matthias> compiler. _Unwind_Resume, _Unwind_GetRegionStart are Matthias> referenced by glibc objects, _Unwind_GetIP, _Unwind_SetGR, Matthias> _Unwind_SetGR, _Unwind_SetIP are referenced by Matthias> libgcc_eh.a. Found in the standalone libunwind.a: Matthias> g F .text 0060 .protected _Unwind_GetRegionStart Matthias> *UND* _ULia64_get_proc_info Matthias> g F .text 0060 __libunwind_Unwind_GetRegionStart Matthias> a quick fix is to undefine the PROTECTED macro in Matthias> unwind-0.98.3, surely not the right thing to do? A protected symbol is still globally visible, it's just that references from within the library will be bound within the library itself, so I don't understand why this would be needed. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
> On Thu, 9 Dec 2004 12:49:38 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> ok, I'm currently bootstrapping gcc-3.3 with the patch Matthias> attached, a glibc bootstrap using this compiler did Matthias> succeed. I'll upload the fixed gcc-3.3, when bootstrap and Matthias> testsuite finishes. Matthias> -LIB2ADDEH = $(srcdir)/unwind-libunwind.c $(srcdir)/unwind-sjlj.c \ Matthias> - $(srcdir)/unwind-c.c Matthias> +LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c Looks reasonable to me. I'm still not clear why unwind-c.c isn't needed on HP-UX, but that's a separate issue. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
On Thu, Dec 09, 2004 at 12:49:38PM +0100, Matthias Klose wrote: > H. J. Lu writes: > > On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote: > > > > On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL > > > > PROTECTED]> said: > > > > > > Matthias> glibc now fails to build from source: > > > > > > Matthias> undefined reference to `__gcc_personality_v0' > > > > > > Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. > > > > > > I cc'd HJ Lu since he may remember better what the final conclusion > > > was in regards to the personality routine. IIRC, the resolution was > > > that it needs to be provided by libgcc. > > > > We decided that the personality routine shouldn't be the part of > > libunwind.so. For gcc 3.4/4.0, unwind-sjlj.c and unwind-c.c are > > in libgcc_eh.a, unwind-sjlj.c, unwind-c.c, unwind-compat.c and > > unwind-dw2-fde-compat.c are in libgcc_s.so.1. > > ok, I'm currently bootstrapping gcc-3.3 with the patch attached, a > glibc bootstrap using this compiler did succeed. I'll upload the fixed > gcc-3.3, when bootstrap and testsuite finishes. > Why not just backport the 3.4 libunwind patches to 3.3? H.J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
On Thu, Dec 09, 2004 at 01:35:07PM +0100, Matthias Klose wrote: > David Mosberger writes: > > > On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL PROTECTED]> > > > said: > > > > Matthias> glibc now fails to build from source: > > > > Matthias> undefined reference to `__gcc_personality_v0' > > > > Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. > > > > I cc'd HJ Lu since he may remember better what the final conclusion > > was in regards to the personality routine. IIRC, the resolution was > > that it needs to be provided by libgcc. > > works ok until building glibc with the just built > compiler. _Unwind_Resume, _Unwind_GetRegionStart are referenced by > glibc objects, _Unwind_GetIP, _Unwind_SetGR, _Unwind_SetGR, > _Unwind_SetIP are referenced by libgcc_eh.a. Found in the standalone > libunwind.a: > That is wrong. Glibc doesn't use _Unwind_GetRegionStart. Glibc has its own _Unwind_Resume, _Unwind_ForcedUnwind, _Unwind_GetCFA and _Unwind_GetBSP. H.J. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
David Mosberger writes: > > On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL PROTECTED]> > > said: > > Matthias> glibc now fails to build from source: > > Matthias> undefined reference to `__gcc_personality_v0' > > Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. > > I cc'd HJ Lu since he may remember better what the final conclusion > was in regards to the personality routine. IIRC, the resolution was > that it needs to be provided by libgcc. works ok until building glibc with the just built compiler. _Unwind_Resume, _Unwind_GetRegionStart are referenced by glibc objects, _Unwind_GetIP, _Unwind_SetGR, _Unwind_SetGR, _Unwind_SetIP are referenced by libgcc_eh.a. Found in the standalone libunwind.a: g F .text 0060 .protected _Unwind_GetRegionStart *UND* _ULia64_get_proc_info g F .text 0060 __libunwind_Unwind_GetRegionStart a quick fix is to undefine the PROTECTED macro in unwind-0.98.3, surely not the right thing to do? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#284563: libunwind in unstable
H. J. Lu writes: > On Tue, Dec 07, 2004 at 12:16:56AM -0800, David Mosberger wrote: > > > On Tue, 7 Dec 2004 09:01:33 +0100, Matthias Klose <[EMAIL PROTECTED]> > > > said: > > > > Matthias> glibc now fails to build from source: > > > > Matthias> undefined reference to `__gcc_personality_v0' > > > > Argh, looks like we may have to leave unwind-c.c in LIB2ADDEH. > > > > I cc'd HJ Lu since he may remember better what the final conclusion > > was in regards to the personality routine. IIRC, the resolution was > > that it needs to be provided by libgcc. > > We decided that the personality routine shouldn't be the part of > libunwind.so. For gcc 3.4/4.0, unwind-sjlj.c and unwind-c.c are > in libgcc_eh.a, unwind-sjlj.c, unwind-c.c, unwind-compat.c and > unwind-dw2-fde-compat.c are in libgcc_s.so.1. ok, I'm currently bootstrapping gcc-3.3 with the patch attached, a glibc bootstrap using this compiler did succeed. I'll upload the fixed gcc-3.3, when bootstrap and testsuite finishes. --- gcc-3.3-3.3.5/src/gcc/config/t-libunwind2003-12-03 18:18:22.0 -0800 +++ gcc-3.3-3.3.5-fixed/src/gcc/config/t-libunwind 2004-12-04 14:34:40.301003078 -0800 @@ -2,5 +2,4 @@ # so that the resulting libgcc_s.so has the necessary DT_NEEDED entry for # libunwind. SHLIB_LC = -lunwind -lc -LIB2ADDEH = $(srcdir)/unwind-libunwind.c $(srcdir)/unwind-sjlj.c \ - $(srcdir)/unwind-c.c +LIB2ADDEH = $(srcdir)/unwind-sjlj.c $(srcdir)/unwind-c.c -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
> > please review the attached patch. you find the corresponding gcc > package at http://people.debian.org/~doko/gcc-ia64/ > > Matthias > FYI: Accepted: libunwind-setjmp0-dev_0.98.3-2_ia64.deb to pool/main/libu/libunwind/libunwind-setjmp0-dev_0.98.3-2_ia64.deb libunwind-setjmp0_0.98.3-2_ia64.deb to pool/main/libu/libunwind/libunwind-setjmp0_0.98.3-2_ia64.deb libunwind7-dev_0.98.3-2_ia64.deb to pool/main/libu/libunwind/libunwind7-dev_0.98.3-2_ia64.deb libunwind7_0.98.3-2_ia64.deb to pool/main/libu/libunwind/libunwind7_0.98.3-2_ia64.deb libunwind_0.98.3-2.diff.gz to pool/main/libu/libunwind/libunwind_0.98.3-2.diff.gz libunwind_0.98.3-2.dsc to pool/main/libu/libunwind/libunwind_0.98.3-2.dsc Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
> "Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes: Matthias> Matthieu Delahaye writes: >> On Wed, 2004-11-24 at 17:36, Ian Wienand wrote: > On Wed, Nov 24, >> 2004 at 12:46:12AM +0100, Matthias Klose wrote: > > ok, Ian, if >> it's ok with you, I'll prepare a libunwind upload, which > > plays >> well with a libgcc1 package including the libunwind7 shared > > >> libs. Matthias> please review the attached patch. you find the corresponding Matthias> gcc package at http://people.debian.org/~doko/gcc-ia64/ I don't know what's happened, but apt-get upgrade this morning broke the world. Errors were encountered while processing: /var/cache/apt/archives/nano_1.2.4-3_ia64.deb /var/cache/apt/archives/procps_1%3a3.2.4-1_ia64.deb /var/cache/apt/archives/python2.3_2.3.4-16_ia64.deb /var/cache/apt/archives/ethereal_0.10.7-3_ia64.deb /var/cache/apt/archives/pppconfig_2.3.9_all.deb /var/cache/apt/archives/tasksel_2.15_all.deb /var/cache/apt/archives/timidity_2.13.2-5_ia64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) : berry-uni; : berry-uni; sudo apt-get install libunwind apt-get: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory : berry-uni; sudo apt-get install libgcc apt-get: error while loading shared libraries: libunwind.so.7: cannot open shared object file: No such file or directory I had to fetch libunwind7 manually and install it before I could proceed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
Matthieu Delahaye writes:
> On Wed, 2004-11-24 at 17:36, Ian Wienand wrote:
> > On Wed, Nov 24, 2004 at 12:46:12AM +0100, Matthias Klose wrote:
> > > ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which
> > > plays well with a libgcc1 package including the libunwind7 shared
> > > libs.
> >
> > It's actually Matthieu's package so he needs to have the final say so;
> > it's a "rock and a hard place" type problem but FWIW I think having
> > the Mosberger libunwind.so as the default one is an enhancement (and
> > something Debian should have got around to sooner).
>
> Matthias,
>
> I'm not really sure which of the alternatives you proposed earlier is
> now the "official" for libunwind.
>
> File a bug on the BTS against libunwind7 with your patch and explain me
> why. I will upload it either tonight or tomorrow. However, If you think
> it is more urgent than that, please NMU (But please file the bug for
> documentation).
please review the attached patch. you find the corresponding gcc
package at http://people.debian.org/~doko/gcc-ia64/
Matthias
diff -u libunwind-0.98.3/debian/changelog libunwind-0.98.3/debian/changelog
--- libunwind-0.98.3/debian/changelog
+++ libunwind-0.98.3/debian/changelog
@@ -1,3 +1,10 @@
+libunwind (0.98.3-2) unstable; urgency=low
+
+ * Depend on libgcc1, for the sarge release, libunwind.so.7 is built
+by the gcc-3.4 source package.
+
+ -- Matthias Klose <[EMAIL PROTECTED]> Fri, 26 Nov 2004 00:48:43 +0100
+
libunwind (0.98.3-1) unstable; urgency=low
* New upstream release
diff -u libunwind-0.98.3/debian/rules libunwind-0.98.3/debian/rules
--- libunwind-0.98.3/debian/rules
+++ libunwind-0.98.3/debian/rules
@@ -104,6 +104,7 @@
# d_python
dh_makeshlibs
dh_installdeb
+ ln -sf /lib/libunwind.so.7 debian/libunwind7-dev/usr/lib/libunwind.so
dh_shlibdeps
dh_gencontrol
dh_md5sums
diff -u libunwind-0.98.3/debian/control libunwind-0.98.3/debian/control
--- libunwind-0.98.3/debian/control
+++ libunwind-0.98.3/debian/control
@@ -24,7 +24,7 @@
Package: libunwind7
Section: libs
Architecture: ia64
-Depends: ${shlibs:Depends}
+Depends: ${shlibs:Depends}, libgcc1 (>= 1:3.4.3-2)
Description: A library to determine the call-chain of a program - runtime
The primary goal of this project is to define a portable and efficient C
programming interface (API) to determine the call-chain of a program.
diff -u libunwind-0.98.3/debian/libunwind7.install
libunwind-0.98.3/debian/libunwind7.install
--- libunwind-0.98.3/debian/libunwind7.install
+++ libunwind-0.98.3/debian/libunwind7.install
@@ -1,3 +1,2 @@
-debian/tmp/usr/lib/libunwind.so.* usr/lib/
debian/tmp/usr/lib/libunwind-ia64.so.* usr/lib
debian/tmp/usr/lib/libunwind-generic.so.* usr/lib
only in patch2:
unchanged:
--- libunwind-0.98.3.orig/debian/libunwind7.install.saved
+++ libunwind-0.98.3/debian/libunwind7.install.saved
@@ -0,0 +1,3 @@
+debian/tmp/usr/lib/libunwind.so.* usr/lib/
+debian/tmp/usr/lib/libunwind-ia64.so.* usr/lib
+debian/tmp/usr/lib/libunwind-generic.so.* usr/lib
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
On Wed, 2004-11-24 at 17:36, Ian Wienand wrote: > On Wed, Nov 24, 2004 at 12:46:12AM +0100, Matthias Klose wrote: > > ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which > > plays well with a libgcc1 package including the libunwind7 shared > > libs. > > It's actually Matthieu's package so he needs to have the final say so; > it's a "rock and a hard place" type problem but FWIW I think having > the Mosberger libunwind.so as the default one is an enhancement (and > something Debian should have got around to sooner). Matthias, I'm not really sure which of the alternatives you proposed earlier is now the "official" for libunwind. File a bug on the BTS against libunwind7 with your patch and explain me why. I will upload it either tonight or tomorrow. However, If you think it is more urgent than that, please NMU (But please file the bug for documentation). Matthieu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
On Wed, Nov 24, 2004 at 12:46:12AM +0100, Matthias Klose wrote: > ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which > plays well with a libgcc1 package including the libunwind7 shared > libs. It's actually Matthieu's package so he needs to have the final say so; it's a "rock and a hard place" type problem but FWIW I think having the Mosberger libunwind.so as the default one is an enhancement (and something Debian should have got around to sooner). Of course after sarge is released (if any of us are still around ;) someone needs to remember to fix it properly so libgcc depends on libunwind to avoid version skew ... -i signature.asc Description: Digital signature
Re: libunwind in unstable
David Mosberger writes: > > On Wed, 24 Nov 2004 00:26:01 +0100, Matthias Klose <[EMAIL PROTECTED]> > > said: > > Matthias> From my point of view we can get around with it by > Matthias> including the libunwind shared library in libgcc1 for the > Matthias> sarge release. I'm worried about the version skew of the > Matthias> unwind lib ib 0.98.3 and GCC-3.4.3. There's one > Matthias> additional library in libunwind. > > Do you mean libunwind-ia64.so.7.0.0? yes. > That one won't be needed by anything related to GCC (or, more > generally, local unwinding). Having said that, the most recent GDBs > have a soft dependency on libunwind-ia64.so: they'll try to dlopen > libunwind-ia64.so and if that doesn't succeed, fall back on > code-reading (which is very unreliable, but better than nothing at > all). Other than GDB, I can't think of any Debian packages that would > currently rely in libunwind-ia64. ok, Ian, if it's ok with you, I'll prepare a libunwind upload, which plays well with a libgcc1 package including the libunwind7 shared libs. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
> On Wed, 24 Nov 2004 00:26:01 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> From my point of view we can get around with it by Matthias> including the libunwind shared library in libgcc1 for the Matthias> sarge release. I'm worried about the version skew of the Matthias> unwind lib ib 0.98.3 and GCC-3.4.3. There's one Matthias> additional library in libunwind. Do you mean libunwind-ia64.so.7.0.0? That one won't be needed by anything related to GCC (or, more generally, local unwinding). Having said that, the most recent GDBs have a soft dependency on libunwind-ia64.so: they'll try to dlopen libunwind-ia64.so and if that doesn't succeed, fall back on code-reading (which is very unreliable, but better than nothing at all). Other than GDB, I can't think of any Debian packages that would currently rely in libunwind-ia64. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
David Mosberger writes: > > On Tue, 23 Nov 2004 09:27:52 +0100, Matthias Klose <[EMAIL PROTECTED]> > > said: > > Matthias> Is the patch in #278836 a prerequisite for the above > Matthias> changes, or can it be done without it? > > If the gas-patch isn't applied, you run the risk of getting wrong > unwind-info into object-files. For GCC proper, that shouldn't matter > but it could be an issue for the libraries generated by GCC. It's not > all that common to get frame-pointer-relative info on ia64, which is > the only case that's affected, so I suppose we could check the > affected libraries for such info (assuming we can generate a list of > affected libraries). ok, raising the severity to serious. > Matthias> Same question for #278837. > > The hunk for file ptl/sysdeps/unix/sysv/linux/ia64/pt-initfini.c is definitely > needed. The other hunks are needed only when building glibc with a GCC which > has a dependency on -lunwind. so this one is dependent on #278837, but independent of #278835. > Matthias> As an alternative, revert the libunwind patch. > > Which patch are you referring to here? the patch, which introduced the -lunwind support in GCC-3.4.3. > My main concern is to ensure that the toolchain generates correct > unwind-info. That question is independent of whether or not -lunwind > is used by GCC, so I hope we can achieve the former even if the latter > is out of scope at the moment. >From my point of view we can get around with it by including the libunwind shared library in libgcc1 for the sarge release. I'm worried about the version skew of the unwind lib ib 0.98.3 and GCC-3.4.3. There's one additional library in libunwind. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libunwind in unstable
> On Tue, 23 Nov 2004 09:27:52 +0100, Matthias Klose <[EMAIL PROTECTED]> > said: Matthias> Is the patch in #278836 a prerequisite for the above Matthias> changes, or can it be done without it? If the gas-patch isn't applied, you run the risk of getting wrong unwind-info into object-files. For GCC proper, that shouldn't matter but it could be an issue for the libraries generated by GCC. It's not all that common to get frame-pointer-relative info on ia64, which is the only case that's affected, so I suppose we could check the affected libraries for such info (assuming we can generate a list of affected libraries). Matthias> Same question for #278837. The hunk for file ptl/sysdeps/unix/sysv/linux/ia64/pt-initfini.c is definitely needed. The other hunks are needed only when building glibc with a GCC which has a dependency on -lunwind. Matthias> As an alternative, revert the libunwind patch. Which patch are you referring to here? My main concern is to ensure that the toolchain generates correct unwind-info. That question is independent of whether or not -lunwind is used by GCC, so I hope we can achieve the former even if the latter is out of scope at the moment. --david -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 > > [EMAIL PROTECTED]:/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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
