libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Problem with LT 2.1a


From: Ralf Wildenhues
Subject: Re: Problem with LT 2.1a
Date: Wed, 6 Sep 2006 17:10:13 +0200
User-agent: Mutt/1.5.13 (2006-09-01)

Hello Jeff, all,

* Jeff Squyres wrote on Wed, Sep 06, 2006 at 04:17:33PM CEST:
> 
> 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.

First let me try to point out a workaround for your specific situation:

Since mthca.so is Linux-specific, we can rely on having dlopen available
for the workaround.  Since I assume you would rather not have to modify
the part (3), let's modify (2): Before dlopen("mthca.so") inside
libibverbs, let ompi_plugin do an explicit dlopen("libibverbs.so",
RTLD_GLOBAL).  This should cost almost nothing (no system calls
involved, since libibverbs.so is already opened), and should make the
set of symbols available for the subsequent mthca.so.

Do I understand correctly that since you do not use the lt_dl*search*
functions anyway, adding this functionality to opal would be rather
painless?

(I'm not suggesting that we be done with this, or that you should do
this, merely trying to take pressure off the decision in Libtool.)

> 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.

I concur with Bob; about a handful of packages that need it one way or
the other (after all, it was changed not only for cleanliness, but
because some packages needed it changed).

We could add another interface
  lt_dlopen_flags (const char *filename, int flags);

and transport that information through the loader_data?

Or just
  lt_dlopen_set_flags (int flags);

but that again looks ugly from a serialization point of view (since the
user would need to do the locking...).  Unsure.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]