Open MPI logo

Open MPI Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |  

This web mail archive is frozen.

This page is part of a frozen web archive of this mailing list.

You can still navigate around this archive, but know that no new mails have been added to it since July of 2016.

Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.

Subject: Re: [OMPI devel] v1.5 build failure w/ Solaris Studio 12.2 on Linux
From: Paul H. Hargrove (PHHargrove_at_[hidden])
Date: 2012-02-23 12:45:23

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/ (NOT in VT)


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]

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