Trouble with gdb&Linux using transitive linked shared libraries

Trouble with gdb&Linux using transitive linked shared libraries

Post by Guent » Fri, 13 Dec 2002 22:17:21



Hello Everybody,

currently I am porting a huge Softwareproject to Linux, where we
excessively used shared libraries ( *.so ), and of course all the
kinds of transitive/
recursive dependencies in the software project.
That means executable A links against libB.so, which itself is linked
against libC.so and libD.so, they are again.... and so on.

After some trouble with ld, (-rpath <directory> additional to
-L<directory> as on other Unix systems), we finally got it running on
Linux.
But still, I am facing a lot of troubles in Debugging this kind of
application,
since (ddd/)gdb does wierd things with dynamic loading of those
libraries.

A) gdb opens only locally (cwd) available libraries - ignoring
LD_LIBRARY_PATH

B) (The most serios problem) On running "A", gdb complains about
unresolved symbols of libB.so, which are defined in libC.so, which are
available by
proper runtime linking - and are running without gdb.

Who has some answers - faced the same problems - solutions etc. ?
I cannot develop software without having a proper de*.

Currently we are using gcc 2.95.3 / gdb 5.0

Thanks in advance,

Guenter

 
 
 

Trouble with gdb&Linux using transitive linked shared libraries

Post by John Reise » Sat, 14 Dec 2002 00:31:39


[re: trouble with gdb and transitive shared libraries]

gdb 5.2-2 works better for me than previous 5.x versions.

Give the command "set stop-on-solib-events 1" to get a breakpoint
every time that gdb thinks shared libraries have changed.
Use "info sharedlibrary" to find out what gdb thinks the state is.
Investigate the commands
        add-shared-symbol-files
        add-symbol-file
for manually dealing with symbols.  (Yes, add-symbol-file has had a bug
in requiring a literal constant address of .text, instead of an expression.)
Use "objdump --section-headers foo.so  |  grep text" to get the offset
of .text, and remember to prefix with "0x".  Use
        (gdb) info proc
        (gdb) shell
        $ cat /proc/<pid>/maps
        $ exit
to get the kernel's view of what pages are mapped, which is closer to
the authoritative answer than any ld-linux + gdb list.

 
 
 

Trouble with gdb&Linux using transitive linked shared libraries

Post by Paul Pluzhniko » Sat, 14 Dec 2002 14:05:36



> A) gdb opens only locally (cwd) available libraries - ignoring
> LD_LIBRARY_PATH

You probably reset LD_LIBRARY_PATH in your .cshrc/.bashrc ...

When gdb execs the program, it creates a new shell, and if
LD_LIBRARY_PATH is not correct in *that* shell, your exe will
not work.

To verify:

  (gdb) shell
  $ echo $LD_LIBRARY_PATH

If this is indeed what is happening, modify your .{csh,bash}rc
such that it leaves all environment alone for non-interactive shells.

Cheers,
--
In order to understand recursion you must first understand recursion.

 
 
 

1. shared libraries: want implicit transitive closure at link-time

Say I have an executable E which calls functions defined in shared library S.
S, in turn, calls functions defined in shared libraries A, B, and C.

Currently, when I create S
    cc -shared -o libS.so S1.o S2.o ...
I don't get any indication that it has unresolved references.  Instead, when
I create E
    cc -o E E.o libS.so
it complains that libS.so has unresolved references (to functions which I
know are resolved by A, B, and C). So I have to
    cc -o E E.o libS.so libA.so libB.so libC.so
to satisfy the linker.

Instead, I'd like to create S so that it knows it depends on A, B, and C, and
to have the linker use that information automatically when I create E. (The
motivation being that there are in fact many executables like E, and if S is
changed to include calls to functions defined in D, I don't want to force
every E to add libD.so to its link-line.)

I tried
    cc -shared -o libS.so S1.o S2.o ... libA.so libB.so libC.so
and then just
    cc -o E E.o libS.so
but the linker complained that libS.so depended on libA.so etc which it
couldn't find (despite the fact that libA.so was in fact given with an
absolute path). I threw in options like "-rpath" and "-rpath-link" (suitably
escaped with "-Xlinker"), with no success.

Does anyone know if & how this is supposed to work?

(I've looked at the GCC HOWTO, but section 6 doesn't appear to consider this
situation.)

-Michael Dyck

2. Problems, help needed PLEASE !!!

3. debugging a shared library using gdb on linux

4. my mouse keeps killing X

5. Using gdb with Linux Elf shared object libraries

6. tracing using script

7. gdb & shared library code under Linux

8. Networking

9. Question: Inclusion of shared libraries during linking of shared libraries

10. Static/Shared Library linking using Linux gcc

11. How can i debug a shared library using gdb..

12. debugging shared libraries using gdb

13. Help using gdb with shared libraries and child processes