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 to happen. 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...) Ralph On 5/28/07 8:19 PM, "Jack Howarth" <howa...@bromo.msbb.uc.edu> wrote: > Brian, > 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. > Jack > ps I have posted this issue to Apple's radar bug reporter > as issue 5233061 as well. > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
