* Jeff Squyres (jsquy...@cisco.com) [20150225 21:29]:
> Probably no point in re-testing the ones that already worked.
> /me wishes yet again that shell scripting had a "strict" mode that would
> /yell at you when you use "$foop" instead of "$foo" (and $foop doesn't
> /exist/was never set).
You kn
On Wed, Feb 25, 2015 at 4:14 PM, Jeff Squyres (jsquyres) wrote:
> On Feb 25, 2015, at 4:17 PM, Paul Hargrove wrote:
> >
> > The Linux and Solaris verbs issues are resolved.
>
> Good.
>
> > The BSD results are unchanged.
>
> That means this, right:
>
[...snip...]
Yes, that is what I mean.
>
On Feb 25, 2015, at 4:17 PM, Paul Hargrove wrote:
>
> The Linux and Solaris verbs issues are resolved.
Good.
> The BSD results are unchanged.
That means this, right:
--
On FreeBSD-{8,9,10}/amd64 I don't get past "make check":
Segmentation fault (core dumped)
FAIL: dlopen_test
Oddly, my Fr
The Linux and Solaris verbs issues are resolved.
The BSD results are unchanged.
-Paul [Sent from my phone]
On Feb 25, 2015 12:29 PM, "Jeff Squyres (jsquyres)"
wrote:
> Probably no point in re-testing the ones that already worked.
>
> The m4 typo affected systems that require extra libraries (e.
On Wed, Feb 25, 2015 at 12:29 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
> /me wishes yet again that shell scripting had a "strict" mode that would
> yell at you when you use "$foop" instead of "$foo" (and $foop doesn't
> exist/was never set).
See http://redsymbol.net/articles/unof
Probably no point in re-testing the ones that already worked.
The m4 typo affected systems that require extra libraries (e.g., libibverbs, or
even libdl). Instead of filling in _LIBS, _LIBS was accidentally
being left empty.
/me wishes yet again that shell scripting had a "strict" mode that wo
I've queued new tests for the platforms w/ verbs-related failures.
Is there any point retesting the BSDs as well?
-Paul
On Wed, Feb 25, 2015 at 12:02 PM, Jeff Squyres (jsquyres) <
jsquy...@cisco.com> wrote:
> Sorry, I meant:
>
> bot:hargrove
>
>
> > On Feb 25, 2015, at 3:01 PM, Jeff Squyres (jsq
Sorry, I meant:
bot:hargrove
> On Feb 25, 2015, at 3:01 PM, Jeff Squyres (jsquyres)
> wrote:
>
> Per my prior mail, m4 typo fixed -- could you release the hounds again?
>
>> On Feb 25, 2015, at 2:13 PM, Paul Hargrove wrote:
>>
>>
>> On Wed, Feb 25, 2015 at 10:17 AM, Paul Hargrove wrote:
Per my prior mail, m4 typo fixed -- could you release the hounds again?
> On Feb 25, 2015, at 2:13 PM, Paul Hargrove wrote:
>
>
> On Wed, Feb 25, 2015 at 10:17 AM, Paul Hargrove wrote:
> I did that and just shipped a tarball to get Hargroved.
>
> Tests have been dispatched... I will report c
On Wed, Feb 25, 2015 at 10:17 AM, Paul Hargrove wrote:
> I did that and just shipped a tarball to get Hargroved.
>>
>
> Tests have been dispatched... I will report complete results later today.
> The first of the BSD results should be in soon, and I'll plan to report
> go/nogo.
>
"NOGO"
I don'
On Feb 25, 2015, at 1:17 PM, Paul Hargrove wrote:
>
> Assuming that the new tarball finds dlopen() support in libc on the BSDs then
> I am not going to encounter the new behavior unless I manually disable
> (something like "--enable-mca-no-build=dl-dlopen", right?). To be honest,
> any platfo
On Wed, Feb 25, 2015 at 9:56 AM, Jeff Squyres (jsquyres) wrote:
> On Feb 25, 2015, at 11:51 AM, Dave Goodell (dgoodell)
> wrote:
> >
> >> This is a good question: what should we do here?
> >>
> >> 1. Abort the configure (e.g., insist that the user install libltdl or
> --disable-dlopen)
> >
> > I
On Feb 25, 2015, at 11:51 AM, Dave Goodell (dgoodell)
wrote:
>
>> This is a good question: what should we do here?
>>
>> 1. Abort the configure (e.g., insist that the user install libltdl or
>> --disable-dlopen)
>
> I'd do this. A clear message should make this no big deal for users, and in
New tarball is there that fails if --disable-dlopen is not specified and
neither dl component can be built.
Also has the fix for "look for dlopen in standard libs and then in libdl".
> On Feb 25, 2015, at 11:52 AM, Paul Hargrove wrote:
>
>
> On Wed, Feb 25, 2015 at 8:45 AM, Jeff Squyres (jsq
On Wed, Feb 25, 2015 at 8:45 AM, Jeff Squyres (jsquyres) wrote:
> > 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.
>
> Cool; I'll fix this. ...done.
L
On Feb 25, 2015, at 10:45 AM, Jeff Squyres (jsquyres)
wrote:
> On Feb 24, 2015, at 5:44 PM, Paul Hargrove wrote:
>>
>> 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 switche
On Feb 24, 2015, at 5:44 PM, Paul Hargrove wrote:
>
> 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 s
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
On Tue, Feb 24, 2015 at 1:45 PM, Paul Hargrove 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:
---
On Feb 24, 2015, at 4:45 PM, Paul Hargrove wrote:
>
> Check for dlfcn.h and the dlopen symbol in -ldl.
>
> Then the paranoid part of me wants to note that since you don't try using
> dlopen() in the configure tests you risk encountering platforms with
> non-functional/non-conforming implementa
See two responses inline below.
On Tue, Feb 24, 2015 at 1:08 PM, Jeff Squyres (jsquyres) wrote:
> On Feb 24, 2015, at 1:55 PM, Paul Hargrove wrote:
> >
> > Forgive me for asking a question I am sure I could answer by reading the
> .m4:
> > How are you planning to distinguish which platforms su
On Feb 24, 2015, at 1:55 PM, Paul Hargrove wrote:
>
> Forgive me for asking a question I am sure I could answer by reading the .m4:
> How are you planning to distinguish which platforms support dlopen()?
Check for dlfcn.h and the dlopen symbol in -ldl.
> And the question you should have seen co
Jeff,
+0.95
Read the new PR yesterday and agree it makes sense to bypass libltdl where
it would add little or nothing to a "dlopen-lovin' platform".
Forgive me for asking a question I am sure I could answer by reading the
.m4:
How are you planning to distinguish which platforms support dlopen()?
Short version
=
I think I have a PR that now solves the libltdl issue. See
https://github.com/open-mpi/ompi/pull/410 if you care.
If not one has any objections, I'll merge this tomorrow (Wed 25 Feb 2015).
More detail
===
Original problem (can't upgrade Libtool beyond 2.4.2
24 matches
Mail list logo
