Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Feb 1999 14:32:15 -0500
From:      "Kelly Yancey" <kbyanc@freedomnet.com>
To:        <freebsd-hackers@freebsd.org>
Subject:   symbol export question
Message-ID:  <000201be59e3$0ebbf5c0$1468f0c6@tech.freedomnet.com>

next in thread | raw e-mail | index | archive | help

  I saw a similar question pop up a few days ago relating to Apache's DSO
model, but I never saw an answer. I have a similar problem that I'm hoping
that someone with more dynamic library experience can help me with...

  I have written a program which loads dynamic libraries using dlopen() and
friends to implement optional functionality. The main executable can call
dlsym() to properly resolve the symbols in the libraries and the libraries
can call symbols exported from the main executable. Everything works. Now,
for the trick...the only reason I can get it to work right is because I pass
the -Xlinker -E parameter(s) to gcc so that it tells ld to export *all* the
symbols in each the main executable and the modules. While this works, it
seems like a nasty kludge.
  I looked at the PAM sources under /usr/src/lib/libpam and see that if PAM
is compiled to use dynamic modules, it defines PAM_EXPORT as extern (which
is then in turn used for each symbol declaration to be exported). Well, I
have 2 problems with that:
  1) I can't get it to work for me...I wrote a little test program to try it
out which simply declares a single routine extern, when the module loads and
tries to call the extern'ed routine in the main executable...it says
"unresolved symbol..." The problem goes away as soon as I pass -Xlinker -E
to gcc.
  2) The real program is made of many source files with extern declarations
all over the place to allow other object files to reference those symbols. I
would really prefer if I could only share a subset of those routines with
the modules (ie. only export a select set of functions from the executable).
The same applies to some of the modules (although I don't really care as
much except to prevent symbol conflicts between the main executable and
modules).

  So the question is: what is the proper way to export symbols from an
executable so that dynamicly loaded libraries can access just those symbols
(not all symbols in the executable)? Presumably the same holds true for
building libraries which don't export all of their symbols.

  Oh, and on a related note: the man page for dlopen() indicates that dlopen
invokes _init() and dlclose() invokes _fini() in the dynamic library. My own
testing indicates that while this is true, the standard C library implements
_init() which calls main() (presumably all programs are actually started my
calling _init() which the standard library handles and in turn calls the
familiar main() ...for C at least). I suppose the standard library also
intercepts _fini() and performs cleanup too. I found that I can get around
the preprocessing by passing -nostdlib to gcc and implementing _init() and
_fini() in the libraries myself. Is this advisable? What kind of cleanup
could the standard library possibly be doing in _fini() and is there any
other way for me to hook into to _fini() operation?
  I'de like to be able to dynamically add (or occasionally) remove the
libraries from my process's address space and I need a way for the library
to know when it is getting unloaded so that it can restore and vectors in
the main executable it hooked. I suppose I could implement my own function
in each library which the process calls before dlclose()ing it, but it just
seems so nice to be able to use the function already provided for that
purpose.

  I'm sorry that this e-mail came out so long...I know I'm really trying to
pick some of those brains out there. But I appreciate any help I can get.
Thanks very much in advance,

  Kelly
 ~kbyanc@posi.net~


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000201be59e3$0ebbf5c0$1468f0c6>