On Monday, Nov 13th 2006 at 12:41 -0800, quoth Ulrich Drepper: =>Steven W. Orr wrote: =>> There used to be a tool called mksymdb which ran over your whole system and =>> created a dbm of all or your libraries. Then when you got an unresolved =>> symbol error, you just ran locsym and it immediately told you what library =>> or libraries defined the global. => =>This is something from the days of static linking which should be of no real =>interest these days anymore. Nobody should be any status linking and all DSOs =>should pull in their dependencies automatically. => =>This specific problems wouldn't be adequately analyzed any way. It would tell =>you "link with libc_nonshared.a" but this is not the correct answer. It is =>the offending DSO which should have been linked with that archive, not the =>program spewing out the error message. You're right. I just assumed that DSOs were capable of being run through nm. I see now that you can't. What tool does allow you to see the symbol table of DSOs? How does the linker know what happens at linktime when you link a .so? If it sounds like I'm confused I guess I am. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
