>>>>> On Thu, 3 Jun 2004 16:26:52 +1000, Ian Wienand <[EMAIL PROTECTED]> said:
Ian> On Wed, Jun 02, 2004 at 12:34:52PM -0700, David Mosberger wrote: Ian> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252401 Ian> bit me when I wanted to use ethereal on a newly installed box ... Ian> Basically, missing libraries on link of libpango Ian> As for why it hangs and doesn't crash ... well if you disassemble it Ian> you get (excuse the long lines) Ian> 0x2000000001f82590 <pango_xft_get_font_map+176>: [MIB] nop.m 0x0 Ian> 0x2000000001f82591 <pango_xft_get_font_map+177>: nop.i 0x0 Ian> 0x2000000001f82592 <pango_xft_get_font_map+178>: br.call.sptk.many b0=0x2000000001f82590 <pango_xft_get_font_map+176>;; Ian> so it branches back to the start of it's bundle. It should actually Ian> be a call to g_object_new() I think, but as that's not defined at link Ian> I guess the relocation never gets fixed up or something. The branch is IP-relative and the offset field is zero by default so if the label never got resolved, you'd definitely get an infinite loop. However, I don't understand why the unresolved symbol didn't result in an error message from ld.so. AFAIK, the only way this could legitimately happen is if g_object_new() were defined as a weak reference but that seems implausible (if it were weak, the code would have to check explicitly for its value being NULL). HJ, do you know of another scenario where a call to an undefined symbol would silently be ignored by ld.so? (If you need more context, see the above bugreport URL). --davida
