Never mind, I'm an idiot. I still don't like the wrappers around
lt_dlopen in util, but it might be your best option. Are you looking for
symbols in components or the executable? I assumed the executable, in
which case you might be better off just using dlsym() directly. If you're
looking for a symbol first place it's found, then you can just do:
dlsym(RTLD_DEFAULT, symbol);
The lt_dlsym only really helps if you're running on really obscure
platforms which don't support dlsym and loading "preloaded" components.
Brian
On Wed, 29 Jul 2009, Brian W. Barrett wrote:
What are you trying to do with lt_dlopen? It seems like you should always go
through the MCA base utilities. If one's missing, adding it there seems like
the right mechanism.
Brian
On Wed, 29 Jul 2009, Josh Hursey wrote:
George suggested that to me as well yesterday after the meeting. So we
would create opal interfaces to libtool (similar to what we do with the
event engine). That might be the best way to approach this.
I'll start to take a look at implementing this. Since opal/libltdl is not
part of the repository, is there a 'right' place to put this header? maybe
in opal/util/?
Thanks,
Josh
On Jul 28, 2009, at 6:57 PM, Jeff Squyres (jsquyres) wrote:
Josh - this is almost certainly what happened. Yoibks. Unfortunately,
there's good reasons for it. :(
What about if we proxy calls to lt_dlopen through an opal function call?
-jms
Sent from my PDA. No type good.
----- Original Message -----
From: devel-boun...@open-mpi.org <devel-boun...@open-mpi.org>
To: Open MPI Developers <de...@open-mpi.org>
Sent: Tue Jul 28 16:39:42 2009
Subject: Re: [OMPI devel] libtool issue with crs/self
It was mentioned to me that r21731 might have caused this problem by
restricting the visibility of the libltdl library.
https://svn.open-mpi.org/trac/ompi/changeset/21731
Brian,
Do you have any thoughts on how we might extend the visibility so that
MCA components could also use the libtool in opal?
I can try to initialize libtool in the Self CRS component and use it
directly, but since it is already opened by OPAL, I think it might be
better to use the instantiation in OPAL.
Cheers,
Josh
On Jul 28, 2009, at 3:06 PM, Josh Hursey wrote:
Once upon a time, the Self CRS module worked correctly, but I admit
that I have not tested it in a long time.
The Self CRS component uses dl_open and friends to inspect the
running process for a particular set of functions. When I try to run
an MPI program that contains these signatures I get the following
error when it tries to resolve lt_dlopen() in
opal_crs_self_component_query():
------------------
my-app: symbol lookup error: /path/to/install/lib/openmpi/
mca_crs_self.so: undefined symbol: lt_dlopen
------------------
I am configuring with the following:
------------------
./configure --prefix=/path/to/install \
--enable-binaries \
--with-devel-headers \
--enable-debug \
--enable-mpi-threads \
--with-ft=cr \
--without-memory-manager \
--enable-ft-thread \
CC=gcc CXX=g++ \
F77=gfortran FC=gfortran
------------------
The source code is at the link below:
https://svn.open-mpi.org/trac/ompi/browser/trunk/opal/mca/crs/self
Does anyone have any thoughts on what might be going wrong here?
Thanks,
Josh
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
