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-09 22:00:31


Jeff,

Sorry, but the new opal/util/pth.c in the trunk tarball (1.9a1r30215) fails
to build on NetBSD:

  CC path.lo
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r30215/opal/util/path.c:
In function 'opal_path_nfs':
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r30215/opal/util/path.c:448:19:
error: storage size of 'fsbuf' isn't known
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r30215/opal/util/path.c:478:9:
warning: implicit declaration of function 'statfs'
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r30215/opal/util/path.c:
In function 'opal_path_df':
/home/phargrov/OMPI/openmpi-trunk-netbsd6-i386/openmpi-1.9a1r30215/opal/util/path.c:556:19:
error: storage size of 'buf' isn't known
*** Error code 1

It seems "struct statfs" isn't known and function "statfs" isn't declared.
I was hoping it was a missing include, but it's not that simple.

This system has a manpage for statvfs() but not one for statfs().
However, the generated opal_config.h shows both were detected.

The full config.log is attached, but the following looks to be important:
configure:60191: checking for statfs
configure:60191: gcc -std=gnu99 -o conftest -O3 -DNDEBUG -finline-functions
-fno-strict-aliasing conftest.c -lutil -lm >&5
/var/tmp//ccgSRuv9.o: In function `main':
conftest.c:(.text+0x4): warning: warning: reference to obsolete statfs();
use statvfs()
configure:60191: $? = 0
configure:60191: result: yes

It looks like the ROMIO configure script already has logic for choosing
between statvfs() and statfs(). Perhaps there is something in there you
can crib from.
checking sys/statvfs.h usability... yes
checking sys/statvfs.h presence... yes
checking for sys/statvfs.h... yes
checking whether struct statfs properly defined... no
checking for f_fstypename member of statfs structure... no
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes
checking for stat... yes
checking for st_fstype member of stat structure... no
checking for sys/types.h... (cached) yes
checking for sys/statvfs.h... (cached) yes
checking for sys/vfs.h... (cached) no
checking for statvfs... yes
checking for f_basetype member of statvfs structure... no

-Paul

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