Unresolved references in dynamically loaded shared library (SunOS 4.1.3)

Unresolved references in dynamically loaded shared library (SunOS 4.1.3)

Post by Roger We » Tue, 12 Jan 1993 16:54:48


I am involved in developing an application which requires dynamically loading
and executing functions from shared libraries which don't necessarily exist at
the time the application driver itself is linked.  When these functions in turn
have calls to functions in other shared libraries, ld.so successfully resolves
these references as long their definitions reside in libraries which were
scanned by ld at the time the application driver was linked (system libraries,
for example).

The problem I have run into is that some of these function definitions reside
in other shared libraries which have also been dynamically loaded.  In this
case (unless the references and the definition reside in the same library),
ld.so has no knowledge of these dynamically loaded libraries and therefore
cannot search them.

Is there a way to augment this list of dynamic dependencies at run time so that
the search performed by ld.so can be extended to these dynamically loaded
libraries?  Investigation of the data structures defined in /usr/include/link.h
seems to indicate that there is indeed a way this can be done, if the the
programmer has knowledge of the dynamic linking mechanism beyond what is
available from the Sun manuals.

I would be grateful for any comments or pointers to related material.


   |   Texas Instruments Inc.    TI MSG: RWES                  |
   |   PO Box 149149, MS 2201     Voice: (512) 250-7372        |
   |___Austin, TX 78714-9149________Fax: (512) 250-7104________|


1. Dynamically Loaded Shared Libraries and dbx


Program and libraries have proper common resolution, but dbx doesn't.


Mixed C & FORTRAN main executable exports a common block.
FORTRAN shared library imports the common block.
Main executable dynamically loads shared library (load & loadbind),
then invokes a subroutine in the shared library (exported, of course).
The subroutine references the exported common in the process of
performing it's function.


This program works fine!  Even in dbx.  But dbx doesn't work fine.

While stepping through a subroutine in the library, I attempt to print
the value of a common variable exported from the main executable, and
dbx gives a value which I know not to be true, and which would break
the program if it were.

Here's a partial transcript (with the names changed for clarity) to
show you what I mean.  The main characters are:
    GLOBVAR, a common variable which is exported from the main executable
    LOCVAR, a local variable (in the subroutine)

stopped in file1 at line 96 in file "file1.f"
   96         LOCVAR = GLOBVAR
0 -1
(dbx) n
stopped in file1 at line 97 in file "file1.f"
   97         IPTNDI = 0
51195 -1
(dbx) whatis LOCVAR
 integer*4 locvar
(dbx) whatis GLOBVAR
 integer*4 globvar


I believe that the debugger is looking at a local copy of the common,
rather than the exported copy that the actual code uses.  What I'm
looking for is a way to tell dbx to look at the same common the
program uses.

Since this is a large project, with more than 50 shared libraries,
hundreds of common blocks, thousands of source files, and half a dozen
developers, I'm looking for a general debugging solution which doesn't
require code changes.

I'll summarize to the net.  Thanks.

The above statements are not the opinions or policies of SPSS Inc.
The above statements may not be the opinions of Brent Lambert.
The first disclaimer is a policy of SPSS Inc.
Subsequent disclaimers are probably the opinion of Brent Lambert.

2. asound express (avance als4000)

3. Controlling exports in Dynamically loaded shared libraries

4. Shutdown General Protection Fault

5. dynamically loading shared libraries

6. route real ips

7. Calling Linux-PAM from a dynamically loaded shared library

8. telnet fails

9. Is there a way to load share library dynamically in C on Unix platform?

10. Dynamically Loading a Shared Library on HP-UX

11. unresolved __bzero (cannot load shared library) while using insmod

12. Shared library loading shared library.