Terry / Eugene -- Can you comment?
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 -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
