libogg 1.2.1 contains invalid os_types.h file which causes libvorbis 1.3.1 to be uncompilable
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).