Greetings.
I'm a longtime Libtool user; we've used both Libtool and libltdl in LAM/MPI
and Open MPI (among dozens of other packages!). I've said it before, but
I'll say it again -- thanks bunches for Libtool! I have no idea what we'd
do without it (and for all the help that Ralf W. and others have provided us
over the years).
We have run into a problem with LT 2.1a, however (no worries; we realize
that it's as-yet unreleased). It took a little poking around to realize
what the problem really is: that LT 2.1a's libltdl is no longer
lt_dlopen()'ing plugins on Linux with RTLD_GLOBAL.
Short version: can libltdl be augmented to allow users to optionally specify
using RTLD_GLOBAL? This would solve our problem.
Longer version:
The situation is as follows:
1. Open MPI has a plugin (call it "ompi_plugin") that is linked against a
shared library ("libibverbs.so").
2. At run time, ompi_plugin is lt_dlopen()'ed by the OMPI core.
3. The code in libibverbs in ompi_plugin eventually dlopen()'s its own
plugin (named "mthca.so"; this is a Linux-specific plugin, so libibverbs
directly uses dlopen(), not lt_dlopen())
4. mthca.so requires some symbols in libibverbs, but is not linked against
it.
With LT 1.5.22, this works fine. With LT 2.1a, it doesn't because LT 2.1a's
lt_dlopen() no longer uses RTLD_GLOBAL. Specifically, the dlopen() of
mthca.so fails because it can't access the symbols from libibverbs that are
already loaded in the process.
This is actually a pretty big problem for us; we do not have direct control
over the upstream libibverbs (I might be able to get it changed to link
mtcha.so against libibverbs.so, but there would be at least 2 released,
stable versions of libibverbs that would not work with Open MPI).
I certainly understand the desire to not use RTLD_GLOBAL for everything;
separate namespaces are generally a Good Thing. I guess my appeal is to
allow the caller of lt_dlopen() to optionally specify that they want to use
RTLD_GLOBAL. This would solve our problem.
Are there any estimates of how many other applications will be hurt by this
change to libltdl? We might be among the first of many to ask about this.
:-)
--
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
