On Thu, Jul 19, 2007 at 01:04:27PM -0600, Ralph H Castain wrote:
> I fixed the specific problem of setting the LD_LIBRARY_PATH (and PATH,
> though that wasn't mentioned) for the case of procs spawned locally by
> mpirun - see r15516. Please confirm that the problem is gone and/or let me
> know if i
I fixed the specific problem of setting the LD_LIBRARY_PATH (and PATH,
though that wasn't mentioned) for the case of procs spawned locally by
mpirun - see r15516. Please confirm that the problem is gone and/or let me
know if it persists for you.
The issue of name resolution is a more general probl
Talked with Brian and we have identified the problem and a fix - will come
in later today.
Thanks
Ralph
On 7/19/07 9:24 AM, "Ralph H Castain" wrote:
> You are correct - I misread the note. My bad.
>
> I'll look at how we might ensure the LD_LIBRARY_PATH shows up correctly -
> shouldn't be a
You are correct - I misread the note. My bad.
I'll look at how we might ensure the LD_LIBRARY_PATH shows up correctly -
shouldn't be a big deal.
On 7/19/07 9:12 AM, "George Bosilca" wrote:
> The second execution (the one that you make reference to) is the one
> that works fine. The failing one
The second execution (the one that you make reference to) is the one
that works fine. The failing one is the first one, where
LD_LIBRARY_PATH is not provided. As Gleb indicate using localhost
make the problem vanish.
george.
On Jul 19, 2007, at 10:57 AM, Ralph H Castain wrote:
But it *d
The problem occurs in the following situation. In the rsh PLS the
number of daemons that have to be spawned is set to zero (as mpirun
act now as a daemon). Therefore, the PLS rsh don't do anything except
sending the launch order to the daemons. Then the remaining of the
work is done in the
But it *does* provide an LD_LIBRARY_PATH that is pointing to your openmpi
installation - it says it did it right here in your debug output:
>>> [elfit1:14752] pls:rsh: reset LD_LIBRARY_PATH: /home/glebn/openmpi/lib
I suspect that the problem isn't in the launcher, but rather in the iof
again. Why
It wasn't a bug. There is a bunch of code there just to make sure
PATH and LD_LIBRARY_PATH are set correctly.
Yesterday we discovered that even if you force the --prefix in a
similar execution environment the LD_LIBRARY_PATH doesn't get set.
However, using localhost always solve the problem
On Thu, Jul 19, 2007 at 08:07:51AM -0600, Ralph H Castain wrote:
> Interesting. Apparently, it is getting a NULL back when it tries to access
> the LD_LIBRARY_PATH in your environment. Here is the code involved:
>
> newenv = opal_os_path( false, prefix_dir, lib_base, NULL );
> oldenv = g
Interesting. Apparently, it is getting a NULL back when it tries to access
the LD_LIBRARY_PATH in your environment. Here is the code involved:
newenv = opal_os_path( false, prefix_dir, lib_base, NULL );
oldenv = getenv("LD_LIBRARY_PATH");
if (NULL != oldenv) {
char* temp;
On Wed, Jul 18, 2007 at 09:08:38PM +0300, Gleb Natapov wrote:
> On Wed, Jul 18, 2007 at 09:08:47AM -0600, Ralph H Castain wrote:
> > But this will lockup:
> >
> > pn1180961:~/openmpi/trunk rhc$ mpirun -n 1 -host pn1180961 printenv | grep
> > LD
> >
> > The reason is that the hostname in this last
On Wed, Jul 18, 2007 at 09:08:47AM -0600, Ralph H Castain wrote:
> But this will lockup:
>
> pn1180961:~/openmpi/trunk rhc$ mpirun -n 1 -host pn1180961 printenv | grep
> LD
>
> The reason is that the hostname in this last command doesn't match the
> hostname I get when I query my interfaces, so m
It works for me in both cases, provided I give the fully qualified host name
for your first example. In other words, these work:
pn1180961:~/openmpi/trunk rhc$ mpirun -n 1 -host localhost printenv | grep
LD
[pn1180961.lanl.gov:22021] [0.0] test of print_name
OLDPWD=/Users/rhc/openmpi
LD_LIBRARY_PA
On Wed, Jul 18, 2007 at 07:48:17AM -0600, Ralph H Castain wrote:
> I believe that was fixed in r15405 - are you at that rev level?
I am on the latest revision.
>
>
> On 7/18/07 7:27 AM, "Gleb Natapov" wrote:
>
> > Hi,
> >
> > With current trunk LD_LIBRARY_PATH is not set for ranks that are
I believe that was fixed in r15405 - are you at that rev level?
On 7/18/07 7:27 AM, "Gleb Natapov" wrote:
> Hi,
>
> With current trunk LD_LIBRARY_PATH is not set for ranks that are
> launched on the head node. This worked previously.
>
> --
> Gleb.
>
On Wed, Jul 18, 2007 at 04:27:15PM +0300, Gleb Natapov wrote:
> Hi,
>
> With current trunk LD_LIBRARY_PATH is not set for ranks that are
> launched on the head node. This worked previously.
>
Same more info. I use rsh pls.
elfit1# /home/glebn/openmpi/bin/mpirun -np 1 -H elfit1 env | grep
LD_LI
Hi,
With current trunk LD_LIBRARY_PATH is not set for ranks that are
launched on the head node. This worked previously.
--
Gleb.
17 matches
Mail list logo
