On Sep 15, 2005, at 4:32 PM, Jeff Squyres wrote:
This allows the components themselves to pull in shared libraries when
they are dlopened -- if they need to. If the symbols can be resolved
in the parent process' public symbol namespace, they still will be (as
in the standalone executable example, above). But if they can't be
resolved that way, this gives the ability to explicitly find and pull
in a shared library and resolve the symbols that way (as in the Eclipse
plugin example, above).
I forgot to include the simple example that shows this. Here's how our
components are today (this is the paffinity linux component, but
they're all this way):
[15:15] odin:~/svn/ompi/opal/mca/paffinity/linux % ldd
.libs/mca_paffinity_linux.so
libm.so.6 => /lib/libm.so.6 (0x0000002a9566b000)
libutil.so.1 => /lib/libutil.so.1 (0x0000002a957f1000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0000002a958f4000)
libc.so.6 => /lib/libc.so.6 (0x0000002a95a0b000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
You can see that there's no mention of libopal, even though the
paffinity linux component makes libopal function calls.
Here's how they are after I have fixed the Makefile.am and re-linked it:
[15:16] odin:~/svn/ompi/opal/mca/paffinity/linux % ldd
.libs/mca_paffinity_linux.so
libopal.so.0 => /u/jsquyres/bogus/lib/libopal.so.0
(0x0000002a9565a000)
libm.so.6 => /lib/libm.so.6 (0x0000002a957c8000)
libutil.so.1 => /lib/libutil.so.1 (0x0000002a9594e000)
libnsl.so.1 => /lib/libnsl.so.1 (0x0000002a95a52000)
libc.so.6 => /lib/libc.so.6 (0x0000002a95b68000)
libdl.so.2 => /lib/libdl.so.2 (0x0000002a95d8d000)
/lib64/ld-linux-x86-64.so.2 (0x000000552aaaa000)
Notice the explicit mention of libopal.so. This is what allows the
component to resolve symbols independent of the parent process, if
necessary.
Hope that all makes sense! And if it doesn't, what do you care? :-)
--
{+} Jeff Squyres
{+} The Open MPI Project
{+} http://www.open-mpi.org/
