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]
File was infected with a virus
Note: JP stands for Japanese. ALERT!! This e-mail contained one or more virus-infected files and have been rejected. (JP:コンピュータウィルスを発見しましたので、メールの送信を中止しました。) The following attachments were infected: (JP:[EMAIL PROTECTED]$N$H$*$j!#) file=,status=deleted,virus-id=37368,[EMAIL PROTECTED] Thank you, KDDI Corporation [EMAIL PROTECTED] -- Original message text follows --- Subject: Re: approved Message-ID: [EMAIL PROTECTED] Date: 2004/11/23 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] -- 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]
Bug#219352: Simple test case for xmms/nvidia/TLS bug
True, the error message is not ideal, but if I understand your test case correctly, this only happens when there would have been unresolved symbols anyway. So surely there is another bug here, no? -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#219352: Simple test case for xmms/nvidia/TLS bug
Hi... On Wed, 24 Nov 2004 07:59 am, you wrote: True, the error message is not ideal, but if I understand your test case correctly, this only happens when there would have been unresolved symbols anyway. So surely there is another bug here, no? Quote from dlopen(3): If dlopen() fails for any reason, it returns NULL The point is that dlopen() causes a glibc assertion, and doesn't just fail like it should. Control is never returned to the program. This matters, since you can have the situation where an xmms plugin is installed but its dependencies are not, leading to this highly confusing error message and failure when one starts xmms. =) Peter -- 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 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 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]
