Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] 1.74rc1 build failure: Solaris 11 / x86_64 / Sun Studio 12.3
From: Paul Hargrove (phhargrove_at_[hidden])
Date: 2013-12-19 21:35:06


Jeff,

Solaris 11 / x86_64 build get farther than before, but fails with the
following:

make[2]: Entering directory
`/shared/OMPI/openmpi-1.7.4rc2forpaul-solaris11-x64-ib-gcc452/BLD/ompi/mca/btl/usnic'
  CC btl_usnic_module.lo
In file included from
/shared/OMPI/openmpi-1.7.4rc2forpaul-solaris11-x64-ib-gcc452/openmpi-1.7.4rc2forpaul/ompi/mca/btl/usnic/btl_usnic_module.c:48:0:
/shared/OMPI/openmpi-1.7.4rc2forpaul-solaris11-x64-ib-gcc452/openmpi-1.7.4rc2forpaul/ompi/mca/btl/usnic/btl_usnic_util.h:19:24:
error: expected �=�, �,�, �;�, �asm� or �__attribute__� before �int�
make[2]: *** [btl_usnic_module.lo] Error 1
make[2]: Leaving directory
`/shared/OMPI/openmpi-1.7.4rc2forpaul-solaris11-x64-ib-gcc452/BLD/ompi/mca/btl/usnic'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/shared/OMPI/openmpi-1.7.4rc2forpaul-solaris11-x64-ib-gcc452/BLD/ompi'
make: *** [all-recursive] Error 1

It looks like gcc is choking on __always_inline.
I believe use of __opal_attribute_always_inline__ is the proper fix.
I've made that change and resumed the build... will report again upon
success or the next failure.

I'm not sure why one is trying to build the usnic btl on Solaris at all.
Perhaps just because the OFED stack is present?

-Paul

On Thu, Dec 19, 2013 at 4:39 PM, Jeff Squyres (jsquyres) <jsquyres_at_[hidden]
> wrote:

> Try http://www.open-mpi.org/~jsquyres/unofficial/.
>
> Should have both "if" fixes in it.
>
>
> On Dec 19, 2013, at 7:12 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:
>
> > Jeff,
> >
> > The patch looks fine to my eyes, but I cannot test it:
> >
> > 1) Not sure if email botched withepsace or what, but the patch didn't
> apply to if_posix.c.
> > 2) Even if it did, I don't have sufficiently new autoconf on that system
> to "use" the configure.m4 part of the patch.
> >
> > Any chance of a patched-and-autogen'ed tarball to test?
> >
> > -Paul
> >
> >
> > On Thu, Dec 19, 2013 at 4:04 PM, Jeff Squyres (jsquyres) <
> jsquyres_at_[hidden]> wrote:
> > Paul --
> >
> > Does this patch fix it for you?
> >
> > Index: opal/mca/if/posix_ipv4/configure.m4
> > ===================================================================
> > --- opal/mca/if/posix_ipv4/configure.m4 (revision 29997)
> > +++ opal/mca/if/posix_ipv4/configure.m4 (working copy)
> > @@ -42,8 +42,10 @@
> > )
> >
> > AS_IF([test "$opal_if_posix_ipv4_happy" = "yes"],
> > - [AC_CHECK_MEMBERS([struct ifreq.ifr_mtu], [], [],
> > + [AC_CHECK_MEMBERS([struct ifreq.ifr_hwaddr], [], [],
> > [[#include <net/if.h>]])
> > + AC_CHECK_MEMBERS([struct ifreq.ifr_mtu], [], [],
> > + [[#include <net/if.h>]])
> > ])
> >
> > AS_IF([test "$opal_if_posix_ipv4_happy" = "yes"], [$1], [$2]);
> > Index: opal/mca/if/posix_ipv4/if_posix.c
> > ===================================================================
> > --- opal/mca/if/posix_ipv4/if_posix.c (revision 29997)
> > +++ opal/mca/if/posix_ipv4/if_posix.c (working copy)
> > @@ -263,22 +263,22 @@
> > /* generate CIDR and assign to netmask */
> > intf->if_mask = prefix(((struct sockaddr_in*)
> &ifr->ifr_addr)->sin_addr.s_addr);
> >
> > -#ifdef SIOCGIFHWADDR
> > - /* get the MAC address */
> > - if (ioctl(sd, SIOCGIFHWADDR, ifr) < 0) {
> > - opal_output(0, "btl_usnic_opal_ifinit:
> ioctl(SIOCGIFHWADDR) failed with errno=%d", errno);
> > - break;
> > - }
> > - memcpy(intf->if_mac, ifr->ifr_hwaddr.sa_data, 6);
> > +#ifdef SIOCGIFHWADDR && defined(HAVE_STRUCT_IFREQ_IFR_HWADDR)
> > + /* get the MAC address */
> > + if (ioctl(sd, SIOCGIFHWADDR, ifr) < 0) {
> > + opal_output(0, "opal_ifinit: ioctl(SIOCGIFHWADDR) failed
> with errno=%d", errno);
> > + break;
> > + }
> > + memcpy(intf->if_mac, ifr->ifr_hwaddr.sa_data, 6);
> > #endif
> >
> > #if defined(SIOCGIFMTU) && defined(HAVE_STRUCT_IFREQ_IFR_MTU)
> > - /* get the MTU */
> > - if (ioctl(sd, SIOCGIFMTU, ifr) < 0) {
> > - opal_output(0, "btl_usnic_opal_ifinit:
> ioctl(SIOCGIFMTU) failed with errno=%d", errno);
> > - break;
> > - }
> > - intf->if_mtu = ifr->ifr_mtu;
> > + /* get the MTU */
> > + if (ioctl(sd, SIOCGIFMTU, ifr) < 0) {
> > + opal_output(0, "opal_ifinit: ioctl(SIOCGIFMTU) failed with
> errno=%d", errno);
> > + break;
> > + }
> > + intf->if_mtu = ifr->ifr_mtu;
> > #endif
> >
> > opal_list_append(&opal_if_list, &(intf->super));
> >
> >
> >
> >
> >
> > On Dec 19, 2013, at 6:51 PM, Paul Hargrove <phhargrove_at_[hidden]> wrote:
> >
> > > In 1.7.4rc1's README support is still claimed for Solaris 11 on x86_64
> with Sun Studio (12.2 and 12.3):
> > > - Oracle Solaris 10 and 11, 32 and 64 bit (SPARC, i386, x86_64),
> > > with Oracle Solaris Studio 12.2 and 12.3
> > >
> > > However, I get a build failure when configured with:
> > > CC=cc CFLAGS=-m64 --with-wrapper-cflags=-m64
> > > CXX=CC CXXFLAGS='-m64 -library=stlport4'
> --with-wrapper-cxxflags=-m64
> > > FC=f90 FCFLAGS=-m64 --with-wrapper-fcflags=-m64
> > > --with-openib --prefix=...
> > >
> > > The failure doesn't appear to be compiler specific, and I will be
> testing gcc ASAP.
> > >
> > > make[2]: Entering directory
> `/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/BLD/opal/mca/if/posix_ipv4'
> > > CC if_posix.lo
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/include/opal/sys/amd64/atomic.h",
> line 136: warning: parameter in inline asm statement unused: %3
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/include/opal/sys/amd64/atomic.h",
> line 182: warning: parameter in inline asm statement unused: %2
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/include/opal/sys/amd64/atomic.h",
> line 203: warning: parameter in inline asm statement unused: %2
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/include/opal/sys/amd64/atomic.h",
> line 224: warning: parameter in inline asm statement unused: %2
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/include/opal/sys/amd64/atomic.h",
> line 245: warning: parameter in inline asm statement unused: %2
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/mca/if/posix_ipv4/if_posix.c",
> line 272: undefined struct/union member: ifr_hwaddr
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/mca/if/posix_ipv4/if_posix.c",
> line 272: warning: left operand of "." must be struct/union object
> > >
> "/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/mca/if/posix_ipv4/if_posix.c",
> line 272: cannot access member of non-struct/union object
> > > cc: acomp failed for
> /shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/openmpi-1.7.4rc1/opal/mca/if/posix_ipv4/if_posix.c
> > > make[2]: *** [if_posix.lo] Error 1
> > > make[2]: Leaving directory
> `/shared/OMPI/openmpi-1.7.4rc1-solaris11-x64-ib-ss12u3/BLD/opal/mca/if/posix_ipv4'
> > >
> > > The atomics warnings are concerning (and appear *MANY* times in the
> output).
> > > However the *real* problem is the three errors in
> opal/mca/if/posix_ipv4/if_posix.c", line 272
> > >
> > > Solaris does't have a ifr_hwaddr field in struct if_req.
> > > It *does* have an ifr_addr field, but this posting:
> > >
> http://comments.gmane.org/gmane.os.solaris.opensolaris.networking/12839
> > > suggests that this ioctl probably fails on PF_INET sockets.
> > >
> > > The surrounding code looks like:
> > >
> > > #ifdef SIOCGIFHWADDR
> > > /* get the MAC address */
> > > if (ioctl(sd, SIOCGIFHWADDR, ifr) < 0) {
> > > opal_output(0, "btl_usnic_opal_ifinit:
> ioctl(SIOCGIFHWADDR) failed with errno=%d", errno);
> > > break;
> > > }
> > > memcpy(intf->if_mac, ifr->ifr_hwaddr.sa_data, 6);
> > > #endif
> > >
> > > #if defined(SIOCGIFMTU) && defined(HAVE_STRUCT_IFREQ_IFR_MTU)
> > > /* get the MTU */
> > > if (ioctl(sd, SIOCGIFMTU, ifr) < 0) {
> > > opal_output(0, "btl_usnic_opal_ifinit:
> ioctl(SIOCGIFMTU) failed with errno=%d", errno);
> > > break;
> > > }
> > > intf->if_mtu = ifr->ifr_mtu;
> > > #endif
> > >
> > >
> > > Note the "btl_usnic_open_ifinit:" in the opal_output lines is probably
> a cut-and-paste error.
> > >
> > > -Paul
> > >
> > >
> > >
> > > --
> > > 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
> >
> >
> > --
> > 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
>
>
> --
> 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