I have tried 8 non-mainstream test platforms, using their "/usr/bin/gcc"
MacOS 10.3 (Panther) on PPC:
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)
MacOS 10.4 (Tiger) on PPC:
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
MacOS 10.5 (Leopard) on PPC:
powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5488)
FreeBSD-8.2-RELEASE on amd64:
gcc (GCC) 4.2.1 20070719 [FreeBSD]
FreeBSD-7.2-RELEASE on amd64:
gcc (GCC) 4.2.1 20070719 [FreeBSD]
FreeBSD-6.3-RELEASE on amd64:
gcc (GCC) 3.4.6 [FreeBSD] 20060305
NetBSD-5.1 on amd64:
gcc (GCC) 4.1.3 20080704 prerelease (NetBSD nb2 20081120)
OpenBSD-5.0 on amd64:
gcc (GCC) 4.2.1 20070719
On all but two I was able to configure w/ only a --prefix option, and
then "make", "make install" and "make check" w/o errors (where "gmake"
replaces "make" on the BSD hosts).
On OpenBSD I had to configure with --disable-io-romio, because the build
The errors are the same as I experienced with an older OpenBSD-4.6 on
On MacOS 10.3 (Panther) I experienced the following failure at "make" time:
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../opal/util
> -I../../opal/include -I../../orte/include -I../../ompi/include
> -I../../opal/mca/paffinity/linux/plpa/src/libplpa -I../../.. -I../..
> -I../../../opal/include -I../../../orte/include
> -I../../../ompi/include -D_REENTRANT -O3 -DNDEBUG -finline-functions
> -fno-strict-aliasing -MT path.lo -MD -MP -MF .deps/path.Tpo -c
> ../../../opal/util/path.c -fno-common -DPIC -o .libs/path.o
> ../../../opal/util/path.c: In function `opal_path_nfs':
> ../../../opal/util/path.c:508: error: `MFSTYPENAMELEN' undeclared
> (first use in this function)
> ../../../opal/util/path.c:508: error: (Each undeclared identifier is
> reported only once
> ../../../opal/util/path.c:508: error: for each function it appears in.)
Which is from the following in opal/util/path.c:
> #elif (defined(__APPLE__) && defined(__MACH__))
> for (i = 0; i < FS_TYPES_NUM; i++)
> if (0 == strncasecmp (fs_types[i].f_fsname, buf.f_fstypename,
> goto found;
On this system, it appears that MFSNAMELEN is the proper length (as w/
> $ man statfs | grep NAMELEN
> #define MFSNAMELEN 15 /* length of fs type name, not inc. nul */
> #define MNAMELEN 90 /* length of buffer for returned name */
> char f_fstypename[MFSNAMELEN]; /* fs type name */
> char f_mntonname[MNAMELEN]; /* directory on which
> mounted */
> char f_mntfromname[MNAMELEN]; /* mounted file system */
> $ grep -rl MFSNAMELEN /usr/include/
By editing opal/util/path.c to make that change, I was STILL able to
complete the "make", reaching the following error linking ompi_info:
> /bin/sh ../../../libtool --tag=CXX --mode=link g++ -O3 -DNDEBUG
> -finline-functions -export-dynamic -o ompi_info components.o
> ompi_info.o output.o param.o version.o ../../../ompi/libmpi.la
> libtool: link: g++ -O3 -DNDEBUG -finline-functions -o .libs/ompi_info
> components.o ompi_info.o output.o param.o version.o -Wl,-bind_at_load
> ld: Undefined symbols:
Clearly -lpthread is needed "somewhere", but I didn't pursue this
platform any deeper.
In the unlikely event anybody wants to follow up on either failure, let
There were a fair number of warnings at build time on several of the builds.
I will report any that I find alarming IF/when I've had a chance to pick
Note that I've not *run* any MPI applications yet.
On 12/8/2011 2:13 PM, Jeff Squyres wrote:
> 1.4.5rc1 is now posted in the usual place:
> Gearing up for a pre-Christmas release -- please test! There have only been a few bug fixes since 1.4.4. See http://svn.open-mpi.org/svn/ompi/branches/v1.4/NEWS for details.
> (note that we'll likely have a 1.5.5rc1 shortly, too)
Paul H. Hargrove PHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900