From: Alexandre Oliva (oliva@dcc.unicamp.br)
Date: Thu Jan 07 1999 - 05:07:26 EST
On Jan 7, 1999, Godmar Back <gback@cs.utah.edu> wrote:
>> However, if more than one library is statically linked, it is possible
>> that a symbol from the second library will be found in the dlsym of
>> the first one. libtool may modify this in the future, but this is
>> current state of libltdl.
> From that I conclude that there won't be a static table mapping
> symbol names and values anymore and no more sed scripts to extract them?
Exactly. libtool takes care of creating that table itself, and
libltdl uses it.
> Really, it'd be nice to have a FAQ about how it all works.
Well, we're still working on documenting this in libtool itself, I'm
not willing to duplicate this effort right now...
> What about architectures that don't have a libltdl port?
libltdl currently supports the following dlopening mechanisms: dlopen,
shl_load, GNU DLD and Windows' LoadLibrary. Additionally, it supports
dlopening simulation for platforms that lack shared libraries (or have
shared libraries disabled) through the dlpreopen mechanism, in which a
symbol table is created when the program is linked and it -dlopens a
set of libraries. If any of these libraries is static, libtool will
link the library into the program and add its symbols to the
dlpreopening symbol table. It's that simple.
--
Alexandre Oliva http://www.dcc.unicamp.br/~oliva aoliva@{acm.org}
oliva@{dcc.unicamp.br,gnu.org,egcs.cygnus.com,samba.org}
Universidade Estadual de Campinas, SP, Brasil
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:31 EDT