Re: [OMPI devel] RTLD_GLOBAL question

Jeff, I must admit that I don't completely understand how your fix work. Can you explan me why this veriant was failing: CPPFLAGS="-I$srcdir/opal/libltdl/" AC_EGREP_HEADER([lt_dladvise_init], [$srcdir/opal/libltdl/ltdl.h] while the new one: CPPFLAGS="-I$srcdir -I$srcdir/opal/libltdl/"

Re: [OMPI devel] jenkins runtime failures

Hi Ralph, No problem. My comment about the pull requests was that even if we know something is currently broken in master - resulting in jenkins failures for pull requests - I'd prefer not to get into the mode of just going on and merging the request because we know somethings broken in master.

Re: [OMPI devel] jenkins runtime failures

As for the checks before merge - I suspect this was done exactly that way, if I am right as to the cause. The problem is that it only reproduces for certain conditions and environments. When working in a system with such a wide range of supported setups, you learn to live with the bad as well

Re: [OMPI devel] jenkins runtime failures

> On Dec 3, 2014, at 10:10 AM, Jeff Squyres (jsquyres) > wrote: > > Yes, I am able to replicate. There's some kind of dangling function pointer > in the ORTE event loop during shutdown. It seems to be some kind of race -- > it only happens in some runs, not all (but

Re: [OMPI devel] RTLD_GLOBAL question

Hello Artem, No, but I was also told by schedmd that the slurm we have on our systems is ancient. So I'm no longer considering this problem very important. We have a workaround of always configuring with --disable-dlopen. Thanks, Howard 2014-12-02 20:59 GMT-07:00 Artem Polyakov

Re: [OMPI devel] jenkins runtime failures

Yes, I am able to replicate. There's some kind of dangling function pointer in the ORTE event loop during shutdown. It seems to be some kind of race -- it only happens in some runs, not all (but still pretty frequent). Ralph is looking into it. On Dec 3, 2014, at 1:03 PM, Howard Pritchard

[OMPI devel] knem support in sm btl

We talked during the telecon about the user-reported issue where they asked for knem support, it wasn’t available on the system, but we ran anyway at a reduced performance level. The agreement we had was that OMPI should instead fail at that point since the user had requested something we could

Re: [OMPI devel] RTLD_GLOBAL question

Thanks! On Dec 3, 2014, at 7:03 AM, Artem Polyakov wrote: > > > среда, 3 декабря 2014 г. пользователь Jeff Squyres (jsquyres) написал: > They were equivalent until yesterday. :-) > I see. Got that! > > I was going to file a PR to bring the changes over to v1.8, but not

Re: [OMPI devel] RTLD_GLOBAL question

среда, 3 декабря 2014 г. пользователь Jeff Squyres (jsquyres) написал: > They were equivalent until yesterday. :-) I see. Got that! > > I was going to file a PR to bring the changes over to v1.8, but not until > they had shaken out on master. > > Would you mind filing a PR? Sure, will do that

Re: [OMPI devel] RTLD_GLOBAL question

They were equivalent until yesterday. :-) I was going to file a PR to bring the changes over to v1.8, but not until they had shaken out on master. Would you mind filing a PR? On Dec 3, 2014, at 5:56 AM, Artem Polyakov wrote: > I finally found the clear reason of this

Re: [OMPI devel] RTLD_GLOBAL question

I finally found the clear reason of this strange situation! In ompi opal_setup_libltdl.m4 has the following content: CPPFLAGS="-I$srcdir -I$srcdir/opal/libltdl" AC_EGREP_HEADER([lt_dladvise_init], [opal/libltdl/ltdl.h], [OPAL_HAVE_LTDL_ADVISE=1]) And in ompi-release