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.