[Scummvm-devel] Build of ScummVM 0.8.2 on Solaris 10 x86

Max Horn max at quendi.de
Wed Feb 8 05:18:01 CET 2006


On Mi, Februar 8, 2006 12:02, David Weinehall wrote:
> On Wed, Feb 08, 2006 at 12:38:11PM +0200, Eugene Sandulenko wrote:
>> On Wed, 08 Feb 2006 00:44:06 +0100
>> Laurent Blume <laurent at elanor.org> wrote:
>>
>> > I can, but I need some help to make it properly.
>> >
>> > There are only two errors:
>> >
>> > In file included from ./sword1/animation.h:25,
>> >                  from sword1/animation.cpp:25:
>> > ./graphics/animation.h:34: error: conflicting declaration 'typedef
>> > int8 int8_t'
>> > /usr/include/sys/int_types.h:54: error: 'int8_t' has a previous
>> > declaration as `typedef char int8_t'
>> >
>> > I don't know how to cleanly work around that
>> Rename every int8_t to something like int8_type.
>
> This should (IMHO) be taken care of in the ./configure file; do
> something similar to autoconf; try to use int8_t; if it is already
> defined (it should be on all recent platforms), do nothing, otherwise
> add -DINT8_NEEDED or similar to CFLAGS.  This way we avoid ugly things
> such as int8_type.  The code shouldn't bend over backwards for
> broken platforms.

Actually, the problem in this particular case is that the external header
file  mpeg2dec/mpeg2.h seems to assume that int8_t etc. is defined, when
it really should include the standard header inttypes.h. I consider this a
bug in that header / lib. The Solaris "int_types.h" header is odd, BTW, I
wonder if that is based on an older version of the recent C(++) spec :-).

Anyway, our workaround for that "bug" in mpeg2dec is flawed. The best
immediate workaround, IMO, would be to replace those typedefs in
animation.h by #define's.

On the long run, we may want to consider moving from our uint8, int32 etc.
types to the new standard compliant types defined in inttypes.h. Of
course, we'd still check for the presence of that header, and if it is not
there, we'd still use our own typedefs. But I think that when possible,
it's usually better to use the existing standards as much as possible.
Alas, this is not a quick short term solution!


Cheers,
Max





More information about the Scummvm-devel mailing list