Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] trunk build failure on {Free,Net,Open}BSD
From: Ralph Castain (rhc_at_[hidden])
Date: 2014-01-09 17:36:08


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