On 13 December 2007 at 13:17, Lisandro Dalcin wrote:
| Perhaps I was not clear enough. There are many public ways of
| importing modules in Python. Modules can came mainly from two sources:
| pure Python code, or C compiled code. In the later case (called
| extension modules), they are normally a
On Dec 13, 2007, at 6:01 PM, Brian W. Barrett wrote:
But it is easy for OPen MPI to figure out whether it's statically or
dynamically linked, as libtool compiles the code twice if building
both
static and shared and you could poke at #defines to figure out what's
going on -- easy enough to de
On Thu, 13 Dec 2007, Jeff Squyres wrote:
Specifically: it would probably require some significant hackery in
the OMPI build process to put in a #define that indicates whether OMPI
is being built statically or not. But the AM/LT process shields this
information from the build process by design (
On 12/13/07, Jeff Squyres wrote:
> On Dec 12, 2007, at 7:47 PM, Lisandro Dalcin wrote:
> Specifically: it would probably require some significant hackery in
> the OMPI build process to put in a #define that indicates whether OMPI
> is being built statically or not. But the AM/LT process shields t
On Dec 12, 2007, at 7:47 PM, Lisandro Dalcin wrote:
You should, yes.
OK, but now I realize that I cannot simply call libtool dlopen()
inconditionally, as libmpi.so could not exist in a static lib build.
Right. Or it could be libmpi.dylib (OS X). I don't know if other
extensions exist out
Brian raised a good point -- your project must already have a portable
solution for dlopen() since it's loading your plugin.
Can you not use that?
On Dec 12, 2007, at 8:40 AM, Jeff Squyres wrote:
On Dec 11, 2007, at 9:08 AM, Lisandro Dalcin wrote:
(for a nicely-formatted refresher of the
On 12/12/07, Jeff Squyres wrote:
> On Dec 12, 2007, at 6:32 PM, Lisandro Dalcin wrote:
> > Do I have the libtool API calls available when linking against
> > libmpi.so ?
>
> You should, yes.
OK, but now I realize that I cannot simply call libtool dlopen()
inconditionally, as libmpi.so could not e
On Dec 12, 2007, at 6:32 PM, Lisandro Dalcin wrote:
Yes, this is problematic; dlopen is fun on all the various OS's...
FWIW: we use the Libtool DL library for this kind of portability;
OMPI
itself doesn't have all the logic for the different OS loaders.
Do I have the libtool API calls avai
On 12/12/07, Jeff Squyres wrote:
> Yes, this is problematic; dlopen is fun on all the various OS's...
>
> FWIW: we use the Libtool DL library for this kind of portability; OMPI
> itself doesn't have all the logic for the different OS loaders.
Do I have the libtool API calls available when linking
On Dec 11, 2007, at 9:08 AM, Lisandro Dalcin wrote:
(for a nicely-formatted refresher of the issues, check out
https://svn.open-mpi.org/trac/ompi/wiki/Linkers)
Sorry for the late response...
I've finally 'solved' this issue by using RTLD_GLOBAL for loading the
Python extension module that ac
On 12/10/07, Jeff Squyres wrote:
> Brian / Lisandro --
> I don't think that I heard back from you on this issue. Would you
> have major heartburn if I remove all linking of our components against
> libmpi (etc.)?
>
> (for a nicely-formatted refresher of the issues, check out
> https://svn.open-m
Ok. I was planning to do this for OMPI v1.3 and above; not really
planning to do this for the OMPI v1.2 series. We don't have an exact
timeframe for OMPI v1.3 yet -- best guesses at this point is that
it'll be somewhere in 1HCY08.
On Dec 10, 2007, at 5:03 PM, Brian Granger wrote:
I don
I don't think this will be a problem. We are now setting the flags
correctly and doing a dlopen, which should enable the components to
find everything in libmpi.so. If I remember correctly this new change
would simply make all components compiled in a consistent way.
I will run this by Lisandro
On Oct 16, 2007, at 11:20 AM, Brian Granger wrote:
Wow, that is quite a study of the different options. I will spend
some time looking over things to better understand the (complex)
situation. I will also talk with Lisandro Dalcin about what he thinks
the best approach is for mpi4py.
Brian /
On 10/16/07, Jeff Squyres wrote:
> On Oct 16, 2007, at 11:20 AM, Brian Granger wrote:
>
> > Wow, that is quite a study of the different options. I will spend
> > some time looking over things to better understand the (complex)
> > situation. I will also talk with Lisandro Dalcin about what he th
On Oct 16, 2007, at 11:56 AM, Jeff Squyres wrote:
On Oct 16, 2007, at 11:20 AM, Brian Granger wrote:
Wow, that is quite a study of the different options. I will spend
some time looking over things to better understand the (complex)
situation. I will also talk with Lisandro Dalcin about what
On Oct 16, 2007, at 11:20 AM, Brian Granger wrote:
Wow, that is quite a study of the different options. I will spend
some time looking over things to better understand the (complex)
situation. I will also talk with Lisandro Dalcin about what he thinks
the best approach is for mpi4py. One ques
Jeff,
Wow, that is quite a study of the different options. I will spend
some time looking over things to better understand the (complex)
situation. I will also talk with Lisandro Dalcin about what he thinks
the best approach is for mpi4py. One question though. You said that
nothing had changed
On Oct 12, 2007, at 3:5 PM, Brian Granger wrote:
> My guess is that Rmpi is dynamically loading libmpi.so, but not
> specifying the RTLD_GLOBAL flag. This means that libmpi.so is not
> available to the components the way it should be, and all goes
> downhill from there. It only mostly works becau
Brian,
On 12 October 2007 at 13:55, Brian Granger wrote:
| > My guess is that Rmpi is dynamically loading libmpi.so, but not
| > specifying the RTLD_GLOBAL flag. This means that libmpi.so is not
| > available to the components the way it should be, and all goes
| > downhill from there. It only
> My guess is that Rmpi is dynamically loading libmpi.so, but not
> specifying the RTLD_GLOBAL flag. This means that libmpi.so is not
> available to the components the way it should be, and all goes
> downhill from there. It only mostly works because we do something
> silly with how we link most
> That's the same for R. We don;t touch the innert guts of module loading for
> this . What Hao realized after looking at the corresponding FAQ item was that
> right before calling MPI_Init, one can load libmpi explicitly, and -- and
> that;s the important bit -- set the proper RTLD_GLOBAL argument
On 10 October 2007 at 15:27, Brian Granger wrote:
| I am seeing the same error, but I am using mpi4py (Lisandro Dalcin's
| Python MPI bindings). I don't think that libmpi.so is being dlopen'd
| directly at runtime, but, the shared library that is linked at compile
| time to libmpi.so is probably
I am seeing the same error, but I am using mpi4py (Lisandro Dalcin's
Python MPI bindings). I don't think that libmpi.so is being dlopen'd
directly at runtime, but, the shared library that is linked at compile
time to libmpi.so is probably being loaded at runtime. The odd thing
is that mpi4py has
Brian,
Man you're good! :)
On 10 October 2007 at 13:49, Brian Barrett wrote:
| On Oct 10, 2007, at 1:27 PM, Dirk Eddelbuettel wrote:
| > | Does this happen for all MPI programs (potentially only those that
| > | use the MPI-2 one-sided stuff), or just your R environment?
| >
| > This is the lik
On Oct 10, 2007, at 1:27 PM, Dirk Eddelbuettel wrote:
| Does this happen for all MPI programs (potentially only those that
| use the MPI-2 one-sided stuff), or just your R environment?
This is the likely winner.
It seems indeed due to R's Rmpi package. Running a simple mpitest.c
shows no
erro
Jeff,
Thanks for the reply. I have gotten much closer, and it looks like all
wounds were self-inflicted. More below.
On 9 October 2007 at 22:01, Jeff Squyres wrote:
| On Oct 9, 2007, at 3:50 PM, Dirk Eddelbuettel wrote:
|
| > edd@ron:~$ orterun -n 2 --mca mca_component_show_load_errors 1 r -e
On Oct 9, 2007, at 3:50 PM, Dirk Eddelbuettel wrote:
edd@ron:~$ orterun -n 2 --mca mca_component_show_load_errors 1 r -e
'library(Rmpi); print(mpi.comm.rank(0))'
[ron:18360] mca: base: component_find: unable to open osc pt2pt:
file not found (ignored)
[ron:18361] mca: base: component_find: un
I should say that on FC5, where I see the error, mpi runs just fine.
Brian
On 10/9/07, Dirk Eddelbuettel wrote:
>
> On 8 October 2007 at 22:06, Brian Granger wrote:
> | Also seeing this problem on Fedora Core 5. Any resolution yet?
>
> No, none. With the exact same configuration (encoded in th
On 9 October 2007 at 08:08, Jeff Squyres wrote:
| On Oct 7, 2007, at 12:53 AM, Dirk Eddelbuettel wrote:
|
| > | Not that I can tell. What else could I test? The build-logs
| > don't reveal
| > | anything fishy -- all pt2pt occurrences look fine. The build itself
| > | proceeded fine (and thi
On 8 October 2007 at 22:06, Brian Granger wrote:
| Also seeing this problem on Fedora Core 5. Any resolution yet?
No, none. With the exact same configuration (encoded in the Debian package
build 'recipe' for the package), I get
-- on Debian: 'unable to open osc pt2pt' verbosity but a working
On Oct 7, 2007, at 12:53 AM, Dirk Eddelbuettel wrote:
| Not that I can tell. What else could I test? The build-logs
don't reveal
| anything fishy -- all pt2pt occurrences look fine. The build itself
| proceeded fine (and this was the Debian package build I then uplod)
Two more observations
Also seeing this problem on Fedora Core 5. Any resolution yet?
Brian
On 10/6/07, Dirk Eddelbuettel wrote:
>
> On 6 October 2007 at 09:36, Dirk Eddelbuettel wrote:
> |
> | On 5 October 2007 at 21:31, Brian Barrett wrote:
> | | On Oct 5, 2007, at 8:48 PM, Dirk Eddelbuettel wrote:
> | |
> | | > Wi
On 6 October 2007 at 09:36, Dirk Eddelbuettel wrote:
|
| On 5 October 2007 at 21:31, Brian Barrett wrote:
| | On Oct 5, 2007, at 8:48 PM, Dirk Eddelbuettel wrote:
| |
| | > With the (Debian package of the) current 1.2.4 release, I am seeing
| | > a lot of
| | >
| | > mca: base: component_fin
On 5 October 2007 at 21:31, Brian Barrett wrote:
| On Oct 5, 2007, at 8:48 PM, Dirk Eddelbuettel wrote:
|
| > With the (Debian package of the) current 1.2.4 release, I am seeing
| > a lot of
| >
| > mca: base: component_find: unable to open osc pt2pt: file not
| > found (ignored)
| >
| > th
On Oct 5, 2007, at 8:48 PM, Dirk Eddelbuettel wrote:
With the (Debian package of the) current 1.2.4 release, I am seeing
a lot of
mca: base: component_find: unable to open osc pt2pt: file not
found (ignored)
that I'd like to suppress.
For these Debian packages, we added a (commented-ou
Hi all,
With the (Debian package of the) current 1.2.4 release, I am seeing a lot of
mca: base: component_find: unable to open osc pt2pt: file not found (ignored)
that I'd like to suppress.
For these Debian packages, we added a (commented-out by default) entry to
suppress the Infiniband no
37 matches
Mail list logo
