On May 28, 2007, at 4:57 PM, Jack Howarth wrote:
I have been told that Paraview is one package that exhibits this problem with undefined environ symbols. This will occur in any package which creates its own shared libraries that link in any openmpi shared library that contains the undefined environ symbol. I think it is unreasonably restrictive to force all the application developers who use openmpi to avoid creating shared libs that use openmpi shared libraries. Again from the response on the Darwin mailing list this is expected behavior on Darwin. I will send two patches shortly that address this without needing to touch configure.
Have you tried it? I ask because I have. I created a shared library that called MPI_COMM_SPAWN (to make sure that it called a function that needed environ). Then created an application that called the function in that shared library. Both the new shared library and the application were able to link without problems.
Both the Fink page and the Apple list post indicate that there's a problem *creating* a shared library with undefined symbols. There appears to be no evidence to date that there's a problem creating a shared library that itself does not have undefined symbols but links to an application that does. Given that I was unable to make it fail, I question whether this is a problem.
I'm hesitant to make this change because these types of things are hard to maintain. SInce we don't have a test case that fails, it's impossible to properly test. And since it's obscure and works in the common case, it's unlikely to be properly maintained over the long run. If an example where this fails is presented, I'm happy to make the changes. Until then, it just doesn't make sense. I'm not trying to be unreasonable, but I don't want to add unmaintainable code without at least a direct example of failure.
Brian
