On Wed, Apr 22, 2015 at 4:20 PM, Jeff Squyres (jsquyres) wrote:
> I think we missed 2 commits on v1.8. Filed PR
> https://github.com/open-mpi/ompi-release/pull/254 to fix the problem.
>
> bot:hargrove -- can you test?
>
Initial testing failed autogen.pl (as did Jenkins).
I am past that point an
I think we missed 2 commits on v1.8. Filed PR
https://github.com/open-mpi/ompi-release/pull/254 to fix the problem.
bot:hargrove -- can you test?
> On Apr 21, 2015, at 8:40 PM, Paul Hargrove wrote:
>
>
>
> On Tue, Apr 21, 2015 at 5:33 PM, Jeff Squyres (jsquyres)
> wrote:
> What happens w
On Apr 22, 2015, at 6:18 PM, Marco Atzeri wrote:
>
>> I'm guessing you upgraded your fortran compiler?
>
> eventually just from 4.8.x to 4.9x
Yep -- that would do it. gfortran 4.8.x is is "old enough" Fortran, gfortran
4.9.x is "new enough" Fortran.
>> The usempif08 library is the "use mpi_f
On 4/22/2015 11:19 PM, Jeff Squyres (jsquyres) wrote:
Question:
what is the scope of the new two shared libs
usr/bin/cygmpi_usempi_ignore_tkr-0.dll
usr/bin/cygmpi_usempif08-0.dll
in comparison to previous
usr/bin/cygmpi_mpifh-2.dll
usr/bin/cygmpi_usempi-1.dll
already present in 1.8.4 ?
A
Oops -- missed this when I reviewed / updated README for v1.8. Will fix --
thanks!
> On Apr 22, 2015, at 12:02 AM, Paul Hargrove wrote:
>
> Unless I am mistaken, the text quoted below from README no longer reflects
> the current behavior.
> The text appears to be the same in master and v1.8.
On Apr 22, 2015, at 10:05 AM, Marco Atzeri wrote:
>
> Making all in mpi/fortran/use-mpi-f08
> make[2]: Entering directory
> '/cygdrive/e/cyg_pub/devel/openmpi/openmpi-1.8.5rc2-1.x86_64/build/ompi/mpi/fortran/use-mpi-f08'
> FCLD libmpi_usempif08.la
> .libs/abort_f08.o: In function `mpi_abort
On 4/22/2015 12:43 AM, Jeff Squyres (jsquyres) wrote:
In the usual location:
http://www.open-mpi.org/software/ompi/v1.8/
Making all in mpi/fortran/use-mpi-f08
make[2]: Entering directory
'/cygdrive/e/cyg_pub/devel/openmpi/openmpi-1.8.5rc2-1.x86_64/build/ompi/mpi/fortran/use-mpi-f08'
Unless I am mistaken, the text quoted below from README no longer reflects
the current behavior.
The text appears to be the same in master and v1.8.
-Paul
--with-libltdl(=value)
This option specifies where to find the GNU Libtool libltdl support
library. The following values are permitted:
On Tue, Apr 21, 2015 at 5:33 PM, Jeff Squyres (jsquyres) wrote:
> What happens with master tar balls?
>
Master is fine building dl:dlopen:
--- MCA component dl:dlopen (m4 configuration macro, priority 80)
checking for MCA component dl:dlopen compile mode... static
checking dlfcn.h usability...
What happens with master tar balls?
Sent from my phone. No type good.
On Apr 21, 2015, at 7:38 PM, Paul Hargrove
mailto:phhargr...@lbl.gov>> wrote:
Sorry the output in the previous email left out some relevant detail.
See here that BOTH dl components were unable to compile with the 1.8.5rc2
ta
Sorry the output in the previous email left out some relevant detail.
See here that BOTH dl components were unable to compile with the 1.8.5rc2
tarball:
+++ Configuring MCA framework dl
checking for no configure components in framework dl...
checking for m4 configure components in framework dl...
Is the following configure-fails-by-default behavior really the desired one
in 1.8.5?
I thought this was more of a 1.9 change than a mid-series change.
-Paul
--- MCA component dl:libltdl (m4 configuration macro, priority 50)
checking for MCA component dl:libltdl compile mode... static
checking --
In the usual location:
http://www.open-mpi.org/software/ompi/v1.8/
The NEWS changed completely between rc1 and r2, so I don't know easily exactly
what is different between rc1 and rc2. Here's the full 1.8.5 NEWS:
- Fixed configure problems in some cases when using an external hwloc
insta
13 matches
Mail list logo
