Re: solib-search-path not honoured after program start

["Kris Warkentin" <kewarken@qnx.com>]

> I think this so.
> 
> At first glance, the problem seems to be that update_solib_list() only
> considers mapping newly found shared libraries and not ones that were
> previously known, but which could not be found.
> 
> It might not be too hard to change things so that it attempts to map
> previously unmappable libraries, but I wonder what should happen to
> already mapped and/or loaded shared libraries when solib-search-path
> is changed.  If changing the search path (or the absolute prefix)
> would cause different libraries to be found (than were found
> previously), should the old ones be unmapped/discarded?  (I suspect
> the answer is yes.)
> 
> If so, maybe the right way to fix this problem is to have the
> "set solib-search-path" and "set solib-absolute-prefix" commands
> simply unload all known shared libraries and then invoke solib_add().

What do you think of this?

$ cvs diff -c solib.c
Index: solib.c
===================================================================
RCS file: /cvs/src/src/gdb/solib.c,v
retrieving revision 1.53
diff -c -r1.53 solib.c
*** solib.c     18 Jan 2003 15:55:52 -0000      1.53
--- solib.c     19 Feb 2003 19:57:38 -0000
***************
*** 431,436 ****
--- 431,445 ----
        struct so_list *i = inferior;
        struct so_list **i_link = &inferior;

+       /* if this lib hasn't been read, remove it from gdb's list so
+          that we can try again */
+       if (!gdb->abfd && !gdb->objfile){
+         *gdb_link = gdb->next;
+         free_so (gdb);
+         gdb = *gdb_link;
+         continue;
+       }
+
        /* Check to see whether the shared object *gdb also appears in
         the inferior's current list.  */
        while (i)