Controlling exports in Dynamically loaded shared libraries

Controlling exports in Dynamically loaded shared libraries

Post by fuh » Wed, 12 Feb 2003 21:59:19



I want to create a shared library to be loaded dynamically using
dlopen/dlsym , but I want to control which symbols are available for dlsym.

Here is the problem.

The source for the dynamic llibrary consists of 2 .c files, say file1.c and
file2.c .

There is a variable "int foo" in file1.c that is not declared static because
it is referenced in file2.c ("extern int foo").

However I do not want the variable foo to be accessible with dlsym(, "foo").

How can I prevent this?

I have simialar problems with functions, not just variables.

 
 
 

Controlling exports in Dynamically loaded shared libraries

Post by John Reise » Thu, 13 Feb 2003 00:47:58


 > I want to create a shared library to be loaded dynamically using
 > dlopen/dlsym , but I want to control which symbols are available for dlsym.

info ld
     * Scripts::   Linker Scripts
        * VERSION::   Version Command

 
 
 

Controlling exports in Dynamically loaded shared libraries

Post by fuh » Sat, 15 Feb 2003 00:33:28


got it, thanks.


Quote:> > I want to create a shared library to be loaded dynamically using
>  > dlopen/dlsym , but I want to control which symbols are available for
dlsym.

> info ld
>      * Scripts::   Linker Scripts
>         * VERSION::   Version Command

 
 
 

1. Dynamically Loaded Shared Libraries and dbx

SUMMARY:

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

PROGRAM ARCHITECTURE:

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.

PROBLEM:

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)

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

DISCUSSION:

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. process table full ?

3. Unresolved references in dynamically loaded shared library (SunOS 4.1.3)

4. HELP!!!!!

5. dynamically loading shared libraries

6. Internet IP ermitteln

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

8. format

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. Shared library loading shared library.

12. error in loading shared libraries: libXmu.so.6: cannot open shared object