Hi Brian,
I finally found some time to test your patch and it solves my problem.
Thanks a lot !
Sylvain
On Wed, 27 Oct 2010, Barrett, Brian W wrote:
I found the issue - somehow, we let the priorities used in installdirs get lost
when we rewrote part of the configure system a couple months a
I found the issue - somehow, we let the priorities used in installdirs get lost
when we rewrote part of the configure system a couple months ago. I have a
fix, but it involves changing the configure system, so I won't commit it until
this evening.
Thanks for pointing out the bug!
Brian
On Oc
I'll take a look at fixing this the right way today.
Since I wrote both the original autogen.sh that guaranteed static-components
was ordered and PREFIX code, I had considered it to be a documented feature
that there was strong otdering in the static-components list. So personally,
I'd conside
On Tue, 26 Oct 2010, Jeff Squyres wrote:
I don't think this is the right way to fix it. Sorry! :-(
I don't think it is the right way to do it either :-)
I say this because it worked somewhat by luck before, and now it's
broken. If we put in another "it'll work because of a side effect of a
On Oct 26, 2010, at 6:55 AM, Sylvain Jeaugey wrote:
> This problem may be a detail, but it bugs me a lot, so I'd like to have it
> fixed.
Fair enough. :-)
> Here is a patch that changes the path setting algorithm to "last component
> wins" instead of "first component wins".
>
> This is as wr
Hi all,
This problem may be a detail, but it bugs me a lot, so I'd like to have it
fixed. Here is a patch that changes the path setting algorithm to "last
component wins" instead of "first component wins".
This is as wrong as was the original code, except that it is
consistent with the way a
What you are seeing is just the difference in how the build system (old vs new
vs RPM script) travels across the directory tree. The new build system and RPM
do it in alphabetical order, so config comes before env. The old autogen.sh did
it in reverse alpha order, so env came before config. I do
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.
Ok; let me know what you find.
Thanks!
On Jun 19, 2009, at 7:16 AM, 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.
>>
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 her
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?
--
Jeff Squyres
Cisco Systems
Ok, never mind.
My problem seems related to library generation through RPM, not with
1.3.2, nor the patch.
Sylvain
On Thu, 18 Jun 2009, Sylvain Jeaugey wrote:
Hi all,
Until Open MPI 1.3 (maybe 1.3.1), I used to find it convenient to be able to
move a library from its "normal" place (eithe
FWIW, using OPAL_PREFIX seems to work for me on the trunk and the head
of the v1.3 branch...?
On Jun 18, 2009, at 4:55 AM, Sylvain Jeaugey wrote:
Hi all,
Until Open MPI 1.3 (maybe 1.3.1), I used to find it convenient to be
able
to move a library from its "normal" place (either /usr or /
13 matches
Mail list logo
