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.
On Fri, 15 May 2009, Jeff Squyres wrote:
> Could well be our visibility settings, too... Are those symbols
> 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,RTLD_NOW);
>> printf("Result is %p\n",h);
>> return 0;
>> devel mailing list
"We must accept finite disappointment, but we must never lose infinite
Martin Luther King