I am no expert on this issue. However, having watched those attempting to
maintain the Windows port using the same approach you are advocating, I can
say that requiring APPLE-specific "if...include" logic almost certainly will
be an exercise in frustration, if not futility. Many of us actually develop
Open MPI code on the Mac and have never seen this problem - which indicates
(to me, at least) that we will have great trouble "policing" this
requirement even within that sub-group of the project.
And as for the rest of the developers who work on Linux and other systems -
asking them to "please remember that Darwin requires some strange mojo" is
something we can do, but (based on experience with Windows) is very unlikely
IF a behind-the-scenes solution can be found, that would be far more
preferable. Otherwise, we will likely find us patching releases regularly as
someone else discovers a missing "if APPLE" somewhere in the code.
Alternatively, of course, Darwin could just conform to the rest of the Unix
world... ;-) (just kidding, of course...)
On 5/28/07 8:19 PM, "Jack Howarth" <howarth_at_[hidden]> wrote:
> One general example of why openmpi shouldn't be creating
> shared libraries with undefined environ symbols is as follows.
> If a python based application was using the openmpi shared libraries
> linked into the application's python module, your suggested
> approach would be unusable since the user would have to rebuild
> python to explicitly provide the missing environ symbol. You
> will always run into such corner cases as long as openmpi is
> misbuilt on darwin.
> ps I have posted this issue to Apple's radar bug reporter
> as issue 5233061 as well.
> devel mailing list