On Aug 19, 2000, Greg Eisenhauer <[EMAIL PROTECTED]> wrote:
> My impression of how things stand now is that libtool does support
> creating static versions of programs that use libraries that dlopen(), but:
> 1) the final program (not the library calling dlopen() must include the
> LTDL_SET_PRELOADED_SYMBOLS() macro call, and 2) the program must be linked
> using libtool. If I'm wrong about these, please fill me in on what I should
> be doing.
Correct. I recall some time ago such a program still had to be able
to find the `.la' files for lt_dlopen to succeed. I'm not sure this
is still needed.
> it seems awkward for the program (which does no dlopen()s) to have to
> build libltdl or otherwise acquire ltdl.h so it can use the macro.
The problem is that only when linking the final program can the symbol
table of static libraries be constructed for libltdl.
> Requirement 2 also seems awkward.
Only libtool knows how to merge together all the symbol tables of
static libraries in a way libltdl understands.
Of course, you can figure out your own way to do it, and define new
libltdl back-ends, but then, you'll have to build symbol tables
yourself. In this case, you can use a new feature of libltdl, which
is that of supporting multiple symbol tables, by means of
lt_dlpreload(). You just have to construct symbol tables in the
format expected by libltdl and call this function to tell libltdl
about them.
There's also the issue of using -dlopen to tell libtool you intend to
dlopen a certain library at run-time. If there's no version of the
library that's dlopenable (even if it's a shared library, it may not
have been built with -module or -export-dynamic), libtool will arrange
for the program to be explicitly linked with the library, and libltdl
will be then able to simulate dlopening.
Of course, if all you have is -modules, then all is fine. You don't
really have to call LTDL_SET_PRELOADED_SYMBOLS(), since that's only
needed for `-dlpreopen' to work.
> Requiring libtool to link any program using the library is
> significantly more restrictive.
You can work around it, but it's not that easy. Especially given
that, even if you arrange for your library to handle dlpreopening if
needed, the program will still have to be linked with the dlpreopened
library explicitly.
> As an alternative to these, is it possible that libtool could
> produce the preloaded symbol information and a function to be used
> within the library to initialize using lt_dlpreload()?
This would be possible, yes. But it's not implemented, nor is anyone
working to implement it, AFAIK. Contributions are welcome.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me
