This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
On Feb 24, 2009, at 4:43 AM, Olaf Lenz wrote:
>> We've talked about similar errors before; I thought that the issue
>> was caused by the Python front-end calling dlopen() to manually
>> open the libmpi.so library. Is that the cause in your scenario?
> Not really. We have written a shared library _espresso.so, which is
> a Python module that is loaded by Python, which in turn dynamically
> loads libmpi.so - but only on the C++ level. Python itself never
> sees libmpi.so.
>> If so, note that it needs to load libmpi.so with RTLD_GLOBAL. For
> That is not really under my control, as the library is opened by
As your later post mentioned, there's another topic going on about
exactly this issue right now. I sent a lengthy reply which I think
explains the issues:
>>> the problem disappears. Note also, that the same program works
>>> when I'm
>>> using OpenMPI 1.2.x (tested 1.2.6 and 1.2.9).
> I still wonder, why everything worked fine in 1.2.x, while in
> OpenMPI 1.3 it doesn't. Has anything changed between these versions
> that could influence the behaviour?
Yes; we upgraded our version of Libtool (and libltdl) to the 2.x
series (specifically: Open MPI 1.2.x uses Libtool 1.5.something
whereas Open MPI v1.3.x uses Libtool 2.something). This is an
instance of a change in policy in one of these core tools has ripple
effects on lots and lots of other software...