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.
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".
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:
> 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 H. HargrovePHHargrove_at_[hidden]
Future Technologies Group
HPC Research Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900