Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Development mailing list

Subject: Re: [OMPI devel] v1.5 build failure w/ Solaris Studio 12.2 on Linux
From: Jeffrey Squyres (jsquyres_at_[hidden])
Date: 2012-02-23 12:47:35


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 PHHargrove_at_[hidden]
>>> Future Technologies Group
>>> HPC Research 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
>>>
>>
>
> --
> 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
>
> _______________________________________________
> 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/