On Mon, Jun 13, 2005 at 03:50:08PM -0400, Joey Hess wrote: > Raphael Bossek wrote: > > > Can you give a real-life example please? > > The libxerces1 package where this files exists: > > > > /usr/lib/libxerces1.so.1.7 -> libxerces1.so.1.7.0 > > /usr/lib/libxerces1.so.1.7.0 (SONAME libxerces1.so.1.7) > > > > GDB try to load /usr/lib/debug/usr/lib/libxerces1.so.1.7 as specified > > by SONAME. The symlink is required to get the /usr/lib/debug variant > > of file to get loaded. The fallback is to /usr/lib/libxerces1.so.1.7 > > which does not contain the symbolic information. > > Hmm, I'm suprised that gdb has this problem, it seems like it might make > more sense if it resulved the symlinks and then looked for the debug > file matching the library they pointed to. > > Your patch to make it just copy the symlinks into the debug directory > does look good, but I'd like to hear from Dan first and make sure that > this is not a gdb bug and that we really need to do this.
Well certainly there's more going on than this: please look at /usr/lib/debug/lib and observe that there's only libc-2.3.2.so there, not libc.so.6. The path to the debug file is based on the original file's location, but the basename of the debug file is not; it comes from the .gnu_debuglink section of the object. So, it looks as if that section is not being created correctly. Which one are you stripping to generate the debug info? It should be the real file. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
