but AF_IB is always declared, regardless of actual presence in the kernel.
On Thu, Mar 6, 2014 at 5:56 PM, Ralph Castain <r...@open-mpi.org> wrote:
> Let me see if I can help translate. I think the problem here is Jeff's
> comment about a "run time check", which wasn't actually what he is
> proposing here.
>
> If you look at Jeff's proposed code, what he is saying is that you don't
> need to use AC_TRY_RUN - you can just build based on whether or not AF_IB
> is declared, and so AC_CHECK_DECLS is adequate. If the resulting code
> fails, then that's an error anyway. So you can just protect the code as he
> shows and be done with it.
>
> This would avoid all the warnings we are now receiving on the trunk, and
> do what you need. Make sense?
>
>
>
>
>
> On Thu, Mar 6, 2014 at 7:26 AM, Jeff Squyres (jsquyres) <
> jsquy...@cisco.com> wrote:
>
>> On Mar 6, 2014, at 4:08 AM, Vasily Filipov <vas...@dev.mellanox.co.il>
>> wrote:
>>
>> >> #if HAVE_DECL_AF_IB
>> >> rc = try_using_af_ib();
>> >> if (OMPI_ERR_NOT_AVAILABLE == rc) {
>> >> rc = try_the_other_way();
>> >> }
>> >> #else
>> >> rc = try_the_other_way();
>> >> #endif
>> > I mean I cannot use "another way" if func call for
>> "try_using_af_ib" fails (call for "try_the_other_way()") because RDMACM was
>> compiled for AF_IB usage (different fields in structs, different
>> functions prototypes).
>>
>> Ok, that means the implementation is reduced to:
>>
>> #if HAVE_DECL_AF_IB
>> rc = try_using_af_ib();
>> #else
>> rc = try_the_other_way();
>> #endif
>>
>> Right? If so, I don't see why you need the AC_TRY_RUN -- if RDMACM is
>> easily detectable as to which way it is compiled (because it has, for
>> example, different fields), then AC_CHECK_DECLS should be enough, right?
>>
>> I must be missing something...?
>>
>> --
>> Jeff Squyres
>> jsquy...@cisco.com
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/03/14306.php
>>
>
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/03/14307.php
>
