I suspect that to get this to work for bproc, then we will have to
build mpirun as 64-bit and the library as 32-bit. That's because a
32-bit compiled mpirun calls functions in the 32-bit /usr/lib/
libbroc.so which don't appear to function when the system is booted
64-bit.
Of course that would mean we need heterogeneous support to run on a
single homogeneous system! Will this work on the 1.0 branch?
An alternative worth thinking about is to bypass the library calls
and start processes using a system() call to invoke the bpsh
command. This is a 64-bit executable linked with /usr/lib64/
libbproc.so and which successfully launches both 32- and 64-bit
executables.
I'm currently trying to solve the same issue for LA-MPI :(
David
On Apr 10, 2006, at 9:18 AM, Brian Barrett wrote:
On Apr 10, 2006, at 11:07 AM, David Gunter wrote:
(flashc 105%) mpiexec -n 4 ./send4
[flashc.lanl.gov:09921] mca: base: component_find: unable to open: /
lib/libc.so.6: version `GLIBC_2.3.4' not found (required by /net/
scratch1/dog/flash64/openmpi/openmpi-1.0.2-32b/lib/openmpi/
mca_paffinity_linux.so) (ignored)
[flashc.lanl.gov:09921] mca: base: component_find: unable to open:
libbproc.so.4: cannot open shared object file: No such file or
directory (ignored)
[flashc.lanl.gov:09921] mca: base: component_find: unable to open:
libbproc.so.4: cannot open shared object file: No such file or
directory (ignored)
[flashc.lanl.gov:09921] mca: base: component_find: unable to open:
libbproc.so.4: cannot open shared object file: No such file or
directory (ignored)
[flashc.lanl.gov:09921] mca: base: component_find: unable to open:
libbproc.so.4: cannot open shared object file: No such file or
directory (ignored)
[flashc.lanl.gov:09921] mca: base: component_find: unable to open:
libbproc.so.4: cannot open shared object file: No such file or
directory (ignored)
mpiexec: relocation error: /net/scratch1/dog/flash64/openmpi/
openmpi-1.0.2-32b/lib/openmpi/mca_soh_bproc.so: undefined symbol:
bproc_nodelist
The problem now looks like /lib/libc.so.6 is not longer available.
Indeed, it is available on the compiler nodes but it cannot be found
on the backend nodes - whoops!
Well, that's interesting. Is this on a bproc platform? If so, you
might be best off configuring with either --enable-static or --
disable-dlopen. Either one will prevent components from loading,
which doesn't seem to always work well.
Also, it looks like at least one of the components has a different
libc its linked against than the others. This makes me think that
perhaps you have some old components from a previous build in your
tree. You might want to completely remove your installation prefix
(or lib/openmpi in your installation prefix) and run make install
again.
Are you no longer seeing the errors about epoll?
The other problem is that the -m32 flag didn't make it into mpicc for
some reason.
This is expected behavior. There are going to be more and more cases
where Open MPI provides one wrapper compiler that does the right
thing whether the user passes in -m32 / -m64 (or any of the vendor
options for doing the same thing). So it will be increasingly
impossible for us to know what to add (but as Jeff said, you can tell
configure to always add -m32 to the wrapper compilers if you want).
Brian
___
users mailing list
us...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/users
