This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Multiple instances of libc (ELF shared object)
- To: help-gcc at gnu dot org
- Subject: Multiple instances of libc (ELF shared object)
- From: Arthur Gold <agold at bga dot com>
- Date: Thu, 07 Oct 1999 12:41:59 -0500
- Newsgroups: comp.unix.programmer,gnu.gcc.help
- Xref: wodc7nx0 comp.unix.programmer:4105 gnu.gcc.help:1311
Perhaps someone can help me here.
I have a need, within a shared object, to have multiple instances of
libc in my address space (this has to do with tracing library access),
one to be linked dynamically (by the process that uses the shared
object) and one explicitly dlopen()-ed. Even worse, I need to make sure
that the libraries don't "communicate", i.e.that functions in the
dlopen()-ed version do not accesss code in the normally linked instance.
The straightforward approach does _not_ work as needed, functions from
the 'private' (dlopen()-ed) instance "see" the 'public' version's code
when functions called from within dlsym()-ed calls are linked.
In addition, using multiple libcs seems to mess with the environment
(after dlopen()-ing the second libc, the __environ variable changes) in
ways I don't really understand (yet ;-) ).
Any help would be greatly appreciated!
TIA,
--ag
--
Artie Gold, Austin, TX
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"