Hide Forgot
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 Description of problem: GDB complains of not being able to find a share library file: Error while mapping shared library sections: Here is the fix: About 38 lines into solib_open in solib.c there are three lines that look like: if (found_file < 0 && solib_search_path != NULL) for searching various directories, I think they were copied one from another and that the second and third should not refer to solib_search_path, but should refer to 'get_in_environ (inferior_environ, "PATH")' and 'get_in_environ (inferior_environ, "LD_LIBRARY_PATH")' respectively. Perhaps the following code would be suitable (if get_in_environ returns a null if the env var is not defined): /* If not found, next search the solib_search_path (if any). */ if (found_file < 0 && solib_search_path != NULL) found_file = openp (solib_search_path, 1, in_pathname, O_RDONLY, 0, &temp_pathname); /* If not found, next search the inferior's $PATH environment variable. */ p = get_in_environ (inferior_environ, "PATH"); if (found_file < 0 && p != NULL) found_file = openp (p, 1, in_pathname, O_RDONLY, 0, &temp_pathname); /* If not found, next search the inferior's $LD_LIBRARY_PATH environment variable. */ p = get_in_environ (inferior_environ, "LD_LIBRARY_PATH"); if (found_file < 0 && p != NULL) found_file = openp (p, 1, in_pathname, O_RDONLY, 0, &temp_pathname); The bug that this fixes is that the following error message: Error while mapping shared library sections: was incorrectly generated because solib_open failed to find libraries that were listed in env var "PATH". (The second call to openp was skipped because solib_search_path was being tested when it should have looked for PATH in inferior_environ. Version-Release number of selected component (if applicable): GNU gdb Red Hat Linux (5.2.1-4) How reproducible: Always Steps to Reproduce: 1. (debug core while with shared in an unusual place) 2. 3. Additional info:
Could you please add some more precise steps to reproduce the problem? And a log of the failing gdb?
This happens to me whenever I run gdb on my freshly installed FC2, even on newly compiled code. This is a very high priority bug to me! Here is what it looks like: [bill@localhost bill]$ gdb ~/bin/xplot GNU gdb Red Hat Linux (6.0post-0.20040223.19rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /home/bill/bin/xplot Error while mapping shared library sections: : Success. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. Error while reading shared library symbols: : No such file or directory. etc . . .
Idem for me. It happens to me when I compile a .so (for example. libfoo.so), put it in a directory ($(gen)), link the executable against this .so (-L$(gen) -Wl,-rpath,"" ... -lfoo). I use rpath because at the end I copy the .so in the same directory as the executable. gdb don't reads the shared library symbols of these so files. Am I doing something wrong, or is it gdb's fault? Cheers,
Yes, it is gdb's fault. I supplied the fix and an explanation of what the bug is. Couldn't the gdb team just incorporate the fix into the code? If you look at the current code, it is clearly wrong. I don't have a simple example demonstrate the problem, but then the debugging is already done.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. Note that any bug still open against Red Hat Linux on will be closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still running Red Hat Linux, you are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Closing as CANTFIX.