The "smoke testing" has completed.
While {Free,Net,Open}BSD were a mess, the following worked fine with Jeff's
tarball:
Mac OS X 10.6, 10.7 and 10.8 on x86-64 (LP64 and ILP32 ABIs)
Solaris-10 on SPARC (v8+ and v9 ABIs)
Solaris-11 on X86-64 (LP64 and ILP32 ABIs)
The *BSD platforms when configured with "--enable-static
--disable-shared"
All my x86, x86-64, ppc and ppc64 Linux platforms
I did not test Linux on IA64, MIPS or ARM
-Paul
On Tue, Feb 24, 2015 at 2:44 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
>
>
> On Tue, Feb 24, 2015 at 1:45 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> [...]
>>
>> Smoke testing will begin momentarily...
>>
> [...]
>
> I am choking on all the smoke.
> Somebody call the fire marshall!
>
> It looks like with Jeff's tarball all the BSDs are failing in the same way:
>
> --------------------------------------------------------------------------
> It looks like opal_init failed for some reason; your parallel process is
> likely to abort. There are many reasons that a parallel process can
> fail during opal_init; some of which are due to configuration or
> environment problems. This failure appears to be an internal failure;
> here's some additional information (which may only be relevant to an
> Open MPI developer):
>
> opal_shmem_base_select failed
> --> Returned value -1 instead of OPAL_SUCCESS
> --------------------------------------------------------------------------
>
>
> The most recent master tarball (openmpi-dev-1063-g6c3ddf9.tar.bz2) does
> NOT fail.
> Also, BSDs configured with "--enable-static --disable-shared" do NOT fail.
>
> I took a closer look at the FreeBSD-9/amd64 system (the only non-VM among
> my BSDs).
> The following caught my attention:
>
> +++ Configuring MCA framework dl
> checking for no configure components in framework dl...
> checking for m4 configure components in framework dl... libltdl, dlopen
>
> --- MCA component dl:dlopen (m4 configuration macro, priority 80)
> checking for MCA component dl:dlopen compile mode... static
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... yes
> checking for dlfcn.h... yes
> looking for library without search path
> checking for dlopen in -ldl... no
> checking if MCA component dl:dlopen can compile... no
>
> --- MCA component dl:libltdl (m4 configuration macro, priority 50)
> checking for MCA component dl:libltdl compile mode... static
> checking --with-libltdl value... simple ok (unspecified)
> checking --with-libltdl-libdir value... simple ok (unspecified)
> checking for libltdl dir... compiler default
> checking for libltdl library dir... linker default
> checking ltdl.h usability... no
> checking ltdl.h presence... no
> checking for ltdl.h... no
> checking if MCA component dl:libltdl can compile... no
>
>
> If I read that right there is NO dl component available!
>
> FIRST:
> I believe that *something* should have occurred when no dl component could
> be built.
> Either the build should have been aborted or it could/should have switched
> to building everything static.
> However, the failure at runtime should not have been the eventual outcome.
>
> SECOND:
> On {Free,Net,Open}BSD dlopen() appears in libc, not in libdl.
> So, I suspect one *should* be able to compile dl:dlopen on all these
> systems with the proper configure tests.
>
> I will gladly send any logs and/or output that will help.
>
> -Paul
>
>
> --
> Paul H. Hargrove phhargr...@lbl.gov
> Computer Languages & Systems Software (CLaSS) Group
> Computer Science Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
--
Paul H. Hargrove phhargr...@lbl.gov
Computer Languages & Systems Software (CLaSS) Group
Computer Science Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
