Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] Use of OPAL_PREFIX to relocate a lib
From: Sylvain Jeaugey (sylvain.jeaugey_at_[hidden])
Date: 2010-10-07 08:25:53


Hi list,

Remember this old bug ? I think I finally found out what was going wrong.

The opal "installdirs" framework has two static components : config and
env. These components are automatically detected by the MCA system and
they are listed in opal/mca/installdirs/base/static-components.h.

The problem is that no priority is given, while the order matters : the
first opened component sets the value.

When I build the v1.5 branch, I get 1.env 2.config :
const mca_base_component_t *mca_installdirs_base_static_components[] = {
   &mca_installdirs_env_component,
   &mca_installdirs_config_component,
   NULL
};

When I build an RPM *or* the new default branch, I get 1.config 2.env :
const mca_base_component_t *mca_installdirs_base_static_components[] = {
   &mca_installdirs_config_component,
   &mca_installdirs_env_component,
   NULL
};

I don't know why the generated file is not consistent. It may be related
to the order in which directories are created.

Anyway, the first case seems to be what was intended in the first place.
Since config sets all the values, having it in first position makes env
useless. Besides, in the first configuration, env only needs to sets
OPAL_PREFIX and since config sets all other pathes relatively to
${prefix}, it works.

So, how could we solve this ?

1. Make autogen/configure/whatever generate a consistent
static-components.h with env THEN config ;

2. Add priorities to these components so that env is opened first
regardless of its position in the static components array ;

3. Any other idea ?

Sylvain

On Fri, 19 Jun 2009, Sylvain Jeaugey wrote:

> On Thu, 18 Jun 2009, Jeff Squyres wrote:
>
>> On Jun 18, 2009, at 11:25 AM, Sylvain Jeaugey wrote:
>>
>>> My problem seems related to library generation through RPM, not with
>>> 1.3.2, nor the patch.
>>>
>>
>> I'm not sure I understand -- is there something we need to fix in our SRPM?
>
> I need to dig a bit, but here is the thing : I generated an RPM from the
> official openmpi-1.3.2-1.src.rpm (with some defines like install-in-opt, ...)
> and the OPAL_PREFIX trick doesn't seem to work with it.
>
> But don't take too much time on this, I'll find out why and maybe this is
> just me building it the wrong way.
>
> Sylvain
>
>