Got it; I knew there was a reason -- I just couldn't remember what it was.
If you care, the problem was actually a bug in Libtool's libltdl embedding
machinery. We "fixed" the problem by not embedding libltdl by default any more
(and went a different way...). If you care:
https://github.com/o
On 4/20/2015 5:16 PM, Jeff Squyres (jsquyres) wrote:
I looked at this thread in a little more detail...
The question below is a little moot because of the change that was done to
v1.8, but please humor me anyway. :-)
Macro: I think you told me before, but I forget, so please refresh my memory
I looked at this thread in a little more detail...
The question below is a little moot because of the change that was done to
v1.8, but please humor me anyway. :-)
Macro: I think you told me before, but I forget, so please refresh my memory: I
seem to recall that there's a reason you're invoki
tomorrow is fine .
I am testing octave-4.0.0-rc3 today
;-)
On 4/18/2015 9:13 PM, Ralph Castain wrote:
I am planning on rc2 on Monday, if you’d prefer to wait
On Apr 18, 2015, at 9:30 AM, Marco Atzeri wrote:
Are you planning another rc or I should test the git stable repository ?
I am planning on rc2 on Monday, if you’d prefer to wait
> On Apr 18, 2015, at 9:30 AM, Marco Atzeri wrote:
>
> Are you planning another rc or I should test the git stable repository ?
>
>
> On 4/18/2015 5:10 PM, Ralph Castain wrote:
>> Should now be solved - it was a libtool compatibility iss
Are you planning another rc or I should test the git stable repository ?
On 4/18/2015 5:10 PM, Ralph Castain wrote:
Should now be solved - it was a libtool compatibility issue, and I
updated the 1.8 libtool code
On Apr 18, 2015, at 7:57 AM, Marco Atzeri mailto:marco.atz...@gmail.com>> wrote:
Should now be solved - it was a libtool compatibility issue, and I updated the
1.8 libtool code
> On Apr 18, 2015, at 7:57 AM, Marco Atzeri wrote:
>
> On 4/18/2015 1:01 PM, Jeff Squyres (jsquyres) wrote:
>> Marco --
>>
>> I'm super-late to this -- did this issue get resolved?
>>
>
> Not that
On 4/18/2015 1:01 PM, Jeff Squyres (jsquyres) wrote:
Marco --
I'm super-late to this -- did this issue get resolved?
Not that I am aware of.
I was busy on other things and I did not work further on the matter.
Suggestion for solving it ?
On Apr 7, 2015, at 5:12 PM, Marco Atzeri wrote:
On
Marco --
I'm super-late to this -- did this issue get resolved?
> On Apr 7, 2015, at 5:12 PM, Marco Atzeri wrote:
>
> On 4/7/2015 10:00 PM, Ralph Castain wrote:
>> What version of libtool do you have? We require 2.4.2 - newer versions don’t
>> necessarily work, I fear.
>>
>
> 2.4.6
>
> for
On Apr 6, 2015, at 3:07 PM, Ralph Castain wrote:
>
>> - Don't use inline functions with Clang compiler
>>
>> Without motivation/explanation that sounds like a bad thing.
>
> Some versions of clang (at least >= 3.5 -- perhaps older versions, too?) will
> warn about -finline-functions, but still
Ok, looks good now on MacOS 10.8 (at v1.8.4-189-ga6169b4)
-Paul
On Thu, Apr 9, 2015 at 10:15 AM, Paul Hargrove wrote:
> Ok, Ralph.
> I will test the v1.8 nightly and report.
>
> -Paul
>
> On Thu, Apr 9, 2015 at 10:06 AM, Ralph Castain wrote:
>
>> I committed a fix to the nightly 1.8.5 tarball
Ok, Ralph.
I will test the v1.8 nightly and report.
-Paul
On Thu, Apr 9, 2015 at 10:06 AM, Ralph Castain wrote:
> I committed a fix to the nightly 1.8.5 tarball that fixed it for me.
> However, Rolf tells me that it broke the CUDA support and we are fixing
> that now.
>
> If you don't enable CU
I committed a fix to the nightly 1.8.5 tarball that fixed it for me.
However, Rolf tells me that it broke the CUDA support and we are fixing
that now.
If you don't enable CUDA, then you should be able to test.
On Thu, Apr 9, 2015 at 10:03 AM, Paul Hargrove wrote:
> Ralph,
>
> It appears that Be
Ralph,
It appears that Bert and I have iterated to a correct fix for the VT+Open64
issue.
Did you make any progress on the MacOS issue?
I am using the tarball, and not running autogen, so the system version of
libtool *shouldn't* matter.
However, at least on my Mac, /usr/bin/libtool is not GNU li
Ralph and Bert,
I found a couple issues with the VT fix.
I will document them in the PR when I've finished collecting the outputs..
-Paul
On Wed, Apr 8, 2015 at 8:40 AM, Paul Hargrove wrote:
> Ralph,
>
> According to his comments in the PR, Bert already tested with the same
> compiler that I w
Ralph,
According to his comments in the PR, Bert already tested with the same
compiler that I was using when I originally observed the problem.
So, I had not put a high priority on retesting.
However, I'll see what I can do today.
-Paul
On Wed, Apr 8, 2015 at 8:30 AM, Ralph Castain wrote:
> Th
Thanks Paul!!
The VT fix is in the queue, if/when you can check it. I’m going to look at the
other issue today.
> On Apr 8, 2015, at 8:10 AM, Paul Hargrove wrote:
>
> My 5 ARM and 3 MIPS testers completed without any problems.
>
> The ARM tests include ARMv5, v6, v7 and v8 systems (and inclu
My 5 ARM and 3 MIPS testers completed without any problems.
The ARM tests include ARMv5, v6, v7 and v8 systems (and include both ARM
and THUMB2 ISAs on v7, and AARCH64 on v8)
The MIPS tests include the "32" ABI on a 32-bit (MIPS 4Kc) system, and the
"n32" and "64" ABIs on a 64-bit (MIPS 5Kc) syste
Yeah, that version will cause us problems. We fixed in the master, but bringing
it over to 1.8 is no small thing. I’m waiting for Jeff to return next week
(since he’s the one that created the fix) to decide on best path forward.
> On Apr 7, 2015, at 2:12 PM, Marco Atzeri wrote:
>
> On 4/7/201
On 4/7/2015 10:00 PM, Ralph Castain wrote:
What version of libtool do you have? We require 2.4.2 - newer versions don’t
necessarily work, I fear.
2.4.6
for what I can see opal/mca/backtrace/configure.m4 exist on
the source tree
so it seems a lack of relative/absolute path when invoking
mak
What version of libtool do you have? We require 2.4.2 - newer versions don’t
necessarily work, I fear.
> On Apr 7, 2015, at 12:38 PM, Marco Atzeri wrote:
>
> On 4/5/2015 11:42 PM, Ralph Castain wrote:
>> Usual place:
>>
>> http://www.open-mpi.org/software/ompi/v1.8/
>>
>
> building on cygwi
On 4/5/2015 11:42 PM, Ralph Castain wrote:
Usual place:
http://www.open-mpi.org/software/ompi/v1.8/
building on cygwin64
Making all in libltdl
make[2]: Entering directory
'/cygdrive/e/cyg_pub/devel/openmpi/openmpi-1.8.5rc1-1.x86_64/build/opal/libltdl'
CDPATH="${ZSH_VERSION+.}:" && cd
/pub/
My testing of real hardware is almost complete and I've reported the only
two issues[*] I encountered:
http://www.open-mpi.org/community/lists/devel/2015/04/17183.php
http://www.open-mpi.org/community/lists/devel/2015/04/17184.php
There were roughly 5 failing configurations out of about 70.
> On Apr 6, 2015, at 11:47 AM, Paul Hargrove wrote:
>
> Two comments on the proposed NEWS:
>
>
> - Don't use inline functions with Clang compiler
>
> Without motivation/explanation that sounds like a bad thing.
Some versions of clang (at least >= 3.5 -- perhaps older versions, too?) will
wa
Two comments on the proposed NEWS:
- Don't use inline functions with Clang compiler
>
Without motivation/explanation that sounds like a bad thing.
> - Improved support for Cray
>
Cray's compilers, networks or the programming environment in general?
-Paul
--
Paul H. Hargrove
Usual place:
http://www.open-mpi.org/software/ompi/v1.8/
I'm happy to receive suggestions about the NEWS - here is what I have:
1.8.5
-
- Updated the internal HWLOC with several bug fixes
- Fixed several bugs in OpenSHMEM support
- Extended vader shared memory support to 32-bit architectures
26 matches
Mail list logo
