Hi Jeff,
I have tried --disable-visibility but get the same results. Any other
ideas? I am not able to remove the dlopen, but maybe able to move it to
directly dlopen the mpi library, instead of my library that is linked to
mpi. Is this likely to help?
Nev
On Mon, 2010-04-19 at 09:21 -0400, Jeff S
What version of OMPI are you using? The behavior depends on the version...
On Apr 19, 2010, at 2:01 PM, Martin Siegert wrote:
> Hi,
>
> I am wondering what effects it will have when I configure openmpi
> with --enable-mpi-threads: we are using the TM interface to torque
> and therefore each MPI
Hi all,
Around a year ago, I posted the attached note regarding apparent incorrect file
output results when using OpenMPI >= 1.3.0. I was requested that I generate a
small, self contained bit of code that demonstrates the issue. I have attached
that code to this posting (mpiio.cpp).
You ca
Hi,
I am wondering what effects it will have when I configure openmpi
with --enable-mpi-threads: we are using the TM interface to torque
and therefore each MPI program gets assigned a certain number of cores
on a set of nodes by the scheduler. If the MPI program now starts
additional threads how d
Hi all Open MPI users,
I write a simple MPI program to send a text message to another process. The
code is below.
(test.c)
#include "mpi.h"
#include
#include
#include
int main(int argc, char* argv[]) {
int dest, noProcesses, processId;
MPI_Status status;
char* buffer;
On Apr 19, 2010, at 12:11 PM, Paul Cizmas wrote:
> Here there was a difference - it did work for both cases:
>
> ~$ ABSOFT=foo
> ~$ testme
> ABSOFT=foo
> ~$ export ABSOFT=foo
> ~$ testme
> ABSOFT=foo
> ~$
This could well be because you had previously exported ABSOFT...? (I forget
the exact se
On Apr 19, 2010, at 8:45 AM, Jeff Squyres wrote:
On Apr 19, 2010, at 9:30 AM, Paul Cizmas wrote:
I do note that the compile command line is:
/bin/sh ../../../libtool --mode=compile /Applications/Absoft11.0/
bin/f90 -I../../../ompi/include -I../../../ompi/include -p. -I. -
I../../../ompi/mp
On Mon, Apr 19, 2010 at 9:11 AM, Jeff Squyres wrote:
> On Apr 16, 2010, at 12:05 PM, Baowei Liu wrote:
>
> > Thanks for your reply. Sorry I didn't make it clear. When I run
> config.guess of gcc, it gives me the x86_64 system. But when I run "uname
> -a", it says it's i386. I think that's the
On Apr 19, 2010, at 8:43 AM, Ricardo Reis wrote:
On Mon, 19 Apr 2010, Paul Cizmas wrote:
The ABSOFT is set and exported. I can double check this by doing
"echo $ABSOFT" and it appears that it is okay.
Is it in the path? Besides being set, I mean...
like
export PATH=$ABSOFT:$PATH
just t
On Apr 19, 2010, at 9:30 AM, Paul Cizmas wrote:
> > I do note that the compile command line is:
> >
> > /bin/sh ../../../libtool --mode=compile /Applications/Absoft11.0/
> > bin/f90 -I../../../ompi/include -I../../../ompi/include -p. -I. -
> > I../../../ompi/mpi/f90 -m64 -lU77 -c -o mpi.lo mpi.
On Mon, 19 Apr 2010, Paul Cizmas wrote:
The ABSOFT is set and exported. I can double check this by doing "echo
$ABSOFT" and it appears that it is okay.
Is it in the path? Besides being set, I mean...
like
export PATH=$ABSOFT:$PATH
just trying to cover all corners...
and maybe
export PATH
The ABSOFT is set and exported. I can double check this by doing
"echo $ABSOFT" and it appears that it is okay.
On Apr 19, 2010, at 7:11 AM, Jeff Squyres wrote:
I have not seen this before; environment variables that are defined
in the shell where you invoked "make" should propagate down to
It could well be because of the additional dlopen in your application (we
changed some things from the 1.2 series with regards to this kind of stuff).
Try configuring Open MPI with the --disable-visibility switch and see if that
helps.
On Apr 17, 2010, at 9:05 PM, Nev wrote:
> Hi,
> I am havi
On Apr 16, 2010, at 12:05 PM, Baowei Liu wrote:
> Thanks for your reply. Sorry I didn't make it clear. When I run
> config.guess of gcc, it gives me the x86_64 system. But when I run "uname
> -a", it says it's i386. I think that's the reason OMPI complains about "more
> than one -arch optio
I have not seen this before; environment variables that are defined in the
shell where you invoked "make" should propagate down to the actual process
where the compilers (etc.) are invoked. Is ABSOFT exported, or just set?
I do note that the compile command line is:
/bin/sh ../../../libtool
To be clear, Open MPI essentially requires the ability to open random TCP ports
between the nodes used in the job (it's actually a little less restrictive than
that, but it's easier to describe that requirement than the actual,
less-restrictive requirements).
On Apr 17, 2010, at 10:03 PM, Ral
Whenever I have seen this problem, it has been because of a mismatch between
mpirun and the back-end libraries that are linked against the executable. For
example, the app was compiled/linked against Open MPI a.b.c and either some
other mpirun was used (e.g., from MPICH) or the mpirun from Open
Sorry, reposting this under the correct subject.
FWIW, I took your code compiled it on a linux system using OMPI 1.4
r22761 and Solaris Studio C compilers. Then I ran it with "mpirun -np 4
a.out" and it seems to work for me:
Hello MPI World From process 0: Num processes: 4
Hello MPI World from p
FWIW, I took your code compiled it on a linux system using OMPI 1.4
r22761 and Solaris Studio C compilers. Then I ran it with "mpirun -np 4
a.out" and it seems to work for me:
Hello MPI World From process 0: Num processes: 4
Hello MPI World from process 1!
Hello MPI World from process 2!
Hello
Shiqing,
I am having more import/export issues once I start using the openmpi
binaries that I built with the Microsoft compiler. I get unresolved
symbol errors for MPI::Comm::Comm and for MPI::Datatype::Free when I
link our own program. The C functions MPI_Comm_create and MPI_Type_free
are expo
Shiqing,
I created new projects from scratch using CMake 2.6.4, selected the
source dir and target dir and chose Visual Studio 8 2005 Win64. Pressed
configure twice to accept all the default setting and then generate.
When I open the Visual Studio project file for ompi_info
(ompi\tools\ompi_inf
21 matches
Mail list logo