I'm going to take a stab at this, though Jeff should be the definitive
authority on how this all works.
There is a thread that I think went mostly off-list titled '64bit
shared library problems'.
The old method of not putting lib{opal,orte,mpi}.la (where appropriate)
meant that components were not explicitly linked against those
libraries. Within Open-MPI itself, this is fine. When those
components are dlopen()'d, the application doing so has already loaded
the lib{opal,orte,mpi} libraries in a global scope (RTLD_GLOBAL), so
all symbols are properly (but indirectly) resolved.
Recently a problem came up with someone doing some ompi integration
into Eclipse. What happens there is that the lib{opal,orte,mpi}
libraries are not loaded in a global scope, ie, without RTLD_GLOBAL.
Eclipse has reasons for doing this, though I don't know what they are.
The problem, then, is that when components are loaded, they cannot
resolve the symbols they need from the lib{opal,orte,mpi}.la libraries.
So what this solution does is explicitly link all the components
against the appropriate libraries, thus allowing symbols to be resolved
when the application has not made such libraries available.
Does this help at all?
Andrew
On Sep 22, 2005, at 12:56 PM, George Bosilca wrote:
I think I miss some discussion on the mailing list about the
modification of the Makefile.am. I would like to know why we need this
?
Now we get this message for all .so file we generate:
libtool: install: warning: relinking `*.la'
Thanks,
george.
___
devel mailing list
de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/devel
