Cool; thanks for setting this straight. Doesn't change the outcome, though -- I updated the README (i.e., something like "update your Solaris Studio install!"). We have similar statements about other broken/buggy compilers.
On Feb 23, 2012, at 12:45 PM, Paul H. Hargrove wrote: > Just a Minor correction. Instead of: > > - The C++ part of the build (VT) is deep within the OMPI build; it works fine > with the C compiler all the way up until that point > > The correct facts are: > > - The C++ part of the VT build requires CXXFLAGS=-library=stlport4 when using > the SS12 compilers. > - Addition of that flag leads to the reported error when compiling > ompi/mpi/cxx/file.cc (NOT in VT) > > -Paul > > On 2/23/2012 7:23 AM, Jeffrey Squyres wrote: >> Terry and I talked about this on the phone. Supporting facts (some of these >> are repeated from Paul's prior posts): >> >> - This happens with the C++ SS 12.2 compiler on supported Linux platforms >> - The C++ part of the build (VT) is deep within the OMPI build; it works >> fine with the C compiler all the way up until that point >> - /usr/include/sys/types.h typedefs u_char, and is directly included in >> event.h >> - So SS 12.2/C++ is somehow mucking up<sys/types.h> to make that typedef >> not be available >> - The upgrade from 12.2 to 12.3 is a free download >> >> This feels like a SS 12.2 C++ compiler bug to me. And it's free to upgrade >> to a version that does not have this problem. Hence, this has become a >> README note. >> >> The road to v1.5.5 just got a little shorter. >> >> >> >> On Feb 22, 2012, at 3:16 PM, Paul H. Hargrove wrote: >> >>> I think I have the beginning of a fix for this issue. >>> >>> I had not even noticed earlier that the error in event.h is from the C++ >>> compiler, when compiling file.cxx in the c++ bindings. That makes the >>> vendor-specific addition of "-library=stlport4" to CXXFLAGS quite >>> relevant to the problem/solution. >>> >>> It eventually occurred to me that when VT's sub-configure told me to add >>> configure arguments, I could have used --with-contrib-vt-flags to pass >>> that ONLY to VT and perhaps NOT mess with whatever karma was providing >>> the definition of u_char. However, when I tried that I was disappointed >>> to find that the bit of configure logic that suggests/requires >>> CXXFLAGS=-library=stlport4 (from ompi/contrib/vt/configure.m4) runs >>> BEFORE the processing of --with-contrib-vt-flags. So, that was a dead end. >>> >>> So, the next idea was to look for a fix specific to sltport. I tried >>> adding near the top of opal/event/event.h (after the WINDOWS equivalent): >>>> #ifdef STLPORT >>>> typedef unsigned char u_char; >>>> #endif >>> That managed to clear up the original problem w/ SS12.2. >>> With SS12.3, things also built fine. >>> This suggests the typedef is not "conflicting" with whatever other defn >>> was present. >>> I think the "safety" of this needs to be examined more widely before >>> this can be adopted. >>> My concern is that some system could "typedef char u_char" if it has >>> char unsigned by default, leading to a conflict. >>> Now that would, I suppose, only be a problem if STLPORT is also defined. >>> So, maybe I am over thinking this. >>> >>> -Paul >>> >>> On 2/21/2012 11:10 PM, Paul H. Hargrove wrote: >>>> More notes: >>>> >>>> I've tested ompi-1.5.4 and it has the same problem. So, this is NOT a >>>> regression. >>>> >>>> Terry D. has observed that Ubuntu is NOT a supported platform for the >>>> Solaris Studio compilers. >>>> So, I've reproduced on a Scientific Linux 5.5 platform (Red Hat >>>> Enterprise Linux 5.5 clone, like CentOS) to be sure that was NOT the >>>> cause. >>>> >>>> When I configure for the SS12.x compilers, I've been passing >>>> CXXFLAGS="-library=stlport4" as the VT sub-configure has informed me I >>>> should, due to something wrong the the default STL. I tried dropping >>>> that from configure, and THE BUILD WAS SUCCESSFUL. >>>> >>>> So, one has 2 choices: >>>> + build w/ SS12.2 without VT >>>> + update to SS12.3 and have VT >>>> >>>> I don't think there is sufficient reason to delay 1.5.5 for this. >>>> >>>> -Paul >>>> >>>> On 2/21/2012 4:39 PM, Paul H. Hargrove wrote: >>>>> A few things to note: >>>>> >>>>> 1) This is NOT a problem w/ the SS12.3 compilers on the same machine. >>>>> So, one could say "upgrade your compiler" (a free download) and not >>>>> delay 1.5.5 for this issue. >>>>> >>>>> 2) This is ONLY a problem on Linux, and not on Solaris (both SS12.2 >>>>> and SS12.3 tested for x86, x86-64, Sparc/v9 and Sparc/v8plus) >>>>> >>>>> 3) Testing the trunk I DON'T see the problem with either SS12.2 or >>>>> SS12.3. >>>>> This is interesting, because it probably means that a u_char >>>>> definition is SOMEWHERE in the headers (because libevent *is* getting >>>>> built). >>>>> >>>>> Whatever else may be done, I think this should be fixed "properly" >>>>> (whatever that may equate to) for 1.6. >>>>> The way I see it now, it feels like OMPI is getting a definition of >>>>> u_char only "by accident". >>>>> >>>>> -Paul >>>>> >>>>> On 2/21/2012 12:16 PM, Paul H. Hargrove wrote: >>>>>> Building the v1.5 branch on Linux with the Solaris Studio 12.2 >>>>>> compilers I see the following failure: >>>>>>> "[srcdir]/opal/event/event.h", line 797: Error: Type name expected >>>>>>> instead of "u_char". >>>>>>> "[srcdir]/opal/event/event.h", line 798: Error: Type name expected >>>>>>> instead of "u_char". >>>>>>> "[srcdir]/opal/event/event.h", line 1184: Error: "," expected >>>>>>> instead of "*". >>>>>> Where line 1184 is a prototype containing "u_char *". >>>>>> >>>>>> As far as I can find, only several files below opal/event/ contain >>>>>> any use of "u_char". >>>>>> There is a typedef for u_char in hwloc, but no use that I could see. >>>>>> >>>>>> To the best of my knowledge u_char is NOT defined by any standard, >>>>>> and thus there is no particular header one can reliably find it in. >>>>>> The alternatives, of course are "unsigned char" or "uint8_t" >>>>>> (defined in stdint.h). >>>>>> >>>>>> I had a look at the trunk and VISUALLY is appears the same problem >>>>>> exists in: >>>>>> opal/event/event.h >>>>>> opal/mca/event/libevent2013/libevent/event.h >>>>>> However, my testing is currently confined to the v1.5 branch in the >>>>>> hopes of finally getting the next 1.5.5rc out the door. >>>>>> >>>>>> -Paul >>>>>> >>> -- >>> Paul H. Hargrove phhargr...@lbl.gov >>> Future Technologies Group >>> HPC Research Department Tel: +1-510-495-2352 >>> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 >>> >>> _______________________________________________ >>> devel mailing list >>> de...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel >>> >> > > -- > Paul H. Hargrove phhargr...@lbl.gov > Future Technologies Group > HPC Research Department Tel: +1-510-495-2352 > Lawrence Berkeley National Laboratory Fax: +1-510-486-6900 > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
