No, this is us trying to outsmart compilers. It turned out that at one
point they outsmart us ...
Anyway, I blame the compiler on this one. As we need the definition of the
ompi_free_list_t structure we have to include the header file. We never
use anything from this header file, especially not the ompi_free_list
functions. However, as one of the functions in the header file make a
reference to the ompi_free_list_grow function (defined in the .c file),
the compiler include a reference to this in the library.
george.
On Fri, 15 May 2009, Jeff Squyres wrote:
Could well be our visibility settings, too... Are those symbols
OMPI|ORTE|OPAL_DECLSPEC'ed?
On May 15, 2009, at 10:26 AM, Ashley Pittman wrote:
On Fri, 2009-05-15 at 07:43 -0600, Ralph Castain wrote:
We are running it with 1.3.2, last I heard - haven't tried the current
1.3 branch. Ashley reported a problem with some other symbol that
couldn't be loaded that blocked him on message queue debugging, but
that was on the trunk.
My problem is that the library opens but is expecting to find a symbol
in the application that isn't there, it sounds like terry problem is the
debugger isn't loading the so.
Sounds like we are missing at least a couple of header files.
My first thought for this would be to write a simple C program to
dlopen() the so and see if that works, both with RTLD_NOW and RTLD_LAZY
as I don't know which TotalView uses. Try something like the following.
#include <dlfcn.h>
int main (argc, argv)
int argc;
char *argv[];
{
void *h;
h = dlopen(argv[1],RTLD_NOW);
printf("Result is %p\n",h);
return 0;
}
Ashley,
_______________________________________________
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
"We must accept finite disappointment, but we must never lose infinite
hope."
Martin Luther King
