GitLab

Trying to compile libvorbis 1.3.1 with libogg 1.2.1 results in the following compiler error on Mac OS X 10.6, 32bit mode:

/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include    -I/sw/include  -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement  -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c -o analysis.lo analysis.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -I../include -I/sw/include -I/sw/include -DDARWIN -fno-common -force_cpusubtype_ALL -Wall -g -O4 -ffast-math -fsigned-char -Wdeclaration-after-statement -DUSE_MEMORY_H -MT analysis.lo -MD -MP -MF .deps/analysis.Tpo -c analysis.c  -fno-common -DPIC -o .libs/analysis.o
In file included from /sw/include/ogg/ogg.h:25,
                 from analysis.c:21:
/sw/include/ogg/os_types.h:73: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint16_t'
/sw/include/ogg/os_types.h:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ogg_uint32_t'

Analysis: os_types.h contains this:

#elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */

#  include <inttypes.h>
   typedef int16_t ogg_int16_t;
   typedef u_int16_t ogg_uint16_t;
   typedef int32_t ogg_int32_t;
   typedef u_int32_t ogg_uint32_t;
   typedef int64_t ogg_int64_t;

However, the types u_int16_t and u_int32_t are not defined by inttypes.h resp. stdint.h

Indeed, the correct names for these types as defined by the spec for stdint.h (and by transiency for inttypes.h) are uint32_t and uint16_t. So the simple fix is to change these two lines in libogg's os_types.h.

This may affect #elif cases for other ports which incorrectly expect the u_intFOO types to be defined in stdint.h / inttypes.h

Of course the fact remains that checking for APPLE and MACH is a very fragile way to check for types, and that I would still recommend that os_types.h is rewritten to first try whatever types configure detected, and only fallback to such #define hackery if no configure script can be used... See the (now closed) bug + patch #849 (closed).