Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD
From: Paul Hargrove (phhargrove_at_[hidden])
Date: 2014-01-11 00:37:51


Ralph,

You applied the CMR for this issue (r30256), but the __WINDOWS__ cruft is
all still there.

-Paul

On Thu, Jan 9, 2014 at 2:36 PM, Ralph Castain <rhc_at_[hidden]> wrote:

> The windows reference is stale on that branch - I'll remove it when
> applying the cmr. We no longer support native Windows, and never did on the
> 1.7 series.
>
>
> On Jan 9, 2014, at 2:08 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:
>
> Jeff,
>
> The changes as described in the commit message make good sense to me
> except for one thing:
>
> In the 1.7 branch there is still a defined(__WINDOWS__) case for which
> opal_path_nfs() is currently a no-op . So, I fear that if CMR'ed blindly
> both the configure-time and build-time checks to ensure that at least one
> of statfs() or statvs() will abort the build on Windows. Maybe Marco can
> say more on the subject, but I think Cygwin will detect one or both of the
> stat calls, but opal_path_nfs() will still be a no-op due to the
> __WINDOWS__ guard.
>
>
> I'll be building tonight's trunk tarball on all of my Solaris and *BSD
> systems. So, I can at least confirm that the code builds (finds at least
> one of statfs() or statvfs()) on each platform.
>
> However, only my Solaris (10/SPARC and 11/x86-64) systems have NFS-mounted
> filesystems. So, I don't have any means to ensure that the "newly active"
> code performs correctly on the BSD systems. In other words,
> opal_path_nfs() might continue to always return false on BSD systems and
> I'd not know the difference.
>
> -Paul
>
> P.S. the commit message says "modern flavors of *BSD OSs no longer define
> __BSD", but the FreeBSD-6.3 (circa 2008) system I also test doesn't define
> __BSD either. So, I wonder if this code ever did worked as intended on the
> BSD systems.
>
>
> On Thu, Jan 9, 2014 at 1:30 PM, Jeff Squyres (jsquyres) <
> jsquyres_at_[hidden]> wrote:
>
>> Fixed on trunk in https://svn.open-mpi.org/trac/ompi/changeset/30198.
>>
>> I can't test on all the kinds of systems Paul/Marco have, though -- we'll
>> have to see what happens when he tries.
>>
>>
>> On Jan 9, 2014, at 10:36 AM, Ralph Castain <rhc_at_[hidden]> wrote:
>>
>> > I fully concur - just limited by my available time to fix it. Jeff has
>> volunteered to step in, though.
>> >
>> > On Jan 8, 2014, at 11:44 PM, marco atzeri <marco.atzeri_at_[hidden]>
>> wrote:
>> >
>> >> Il 1/9/2014 5:10 AM, Ralph Castain ha scritto:
>> >>> Actually, as I look at it, the logic escapes me anyway. Basically, you
>> >>> only have two options - use the vfs struct for Sun, and use fs struct
>> >>> for everything else. I'm not aware of any other choice, and indeed the
>> >>> list of all the systems for the latter actually is intended to amount
>> to
>> >>> "anything else".
>> >>>
>> >>> So I just changed it to an "else" statement in the trunk and scheduled
>> >>> it for 1.7.4 if it passes muster - see how this works for you.
>> >>>
>> >>> Ralph
>> >>>
>> >>
>> >> Ralph,
>> >> please note that there are other similar cases in the same file
>> >>
>> >> in "bool opal_path_nfs" function at row 434 and 462
>> >>
>> >> the one at 489 is a multiple if with no default case,
>> >> so the code will fail to perform for any architecture
>> >> no reported there, like CYGWIN, and it is very hard to notice
>> >>
>> >> In general this type of "ifdefined" around platform
>> >> are very bad for portability or platform evolution.
>> >> Adding a new platform will be a hell of work.
>> >>
>> >> The Autoconf approach to portability "should be" to test
>> >> for features, not for versions or platform.
>> >>
>> >> Regards
>> >> Marco
>> >>
>> >> _______________________________________________
>> >> devel mailing list
>> >> devel_at_[hidden]
>> >> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel_at_[hidden]
>> > http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>>
>> --
>> Jeff Squyres
>> jsquyres_at_[hidden]
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/
>>
>> _______________________________________________
>> devel mailing list
>> devel_at_[hidden]
>> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>
>
>
>
> --
> Paul H. Hargrove PHHargrove_at_[hidden]
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>
>
>
> _______________________________________________
> devel mailing list
> devel_at_[hidden]
> http://www.open-mpi.org/mailman/listinfo.cgi/devel
>

-- 
Paul H. Hargrove                          PHHargrove_at_[hidden]
Future Technologies Group
Computer and Data Sciences Department     Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory     Fax: +1-510-486-6900