libogg @1.3.4: error: unknown type name 'uint16_t'

[kencu (Ken)]

I was working on this update yesterday and came across this error on 10.6.8 so I held back on the update -- the solution to which was not immediately obvious to me. Perhaps I was just tired. But I see Chris found it and bumped it, so now it's an official ticket!

/bin/sh ../libtool  --tag=CC   --mode=compile /opt/local/bin/clang-mp-5.0 -DHAVE_CONFIG_H -I. -I..  -I../include -I../include -I/opt/local/include  -fno-common -O4 -Wall -fsigned-char -ffast-math -pipe -Os -arch x86_64 -arch i386 -c -o bitwise.lo bitwise.c
In file included from bitwise.c:23:
In file included from framing.c:29:
In file included from ../include/ogg/ogg.h:24:
../include/ogg/os_types.h:75:12: error: unknown type name 'uint16_t'
   typedef uint16_t ogg_uint16_t;
           ^
In file included from ../include/ogg/ogg.h:24:
../include/ogg/os_types.h:75:12: error: unknown type name 'uint16_t'
   typedef uint16_t ogg_uint16_t;
           ^
../include/ogg/os_types.h:77:12: error: unknown type name 'uint32_t'
   typedef uint32_t ogg_uint32_t;
           ^
../include/ogg/os_types.h:79:12: error: unknown type name 'uint64_t'
   typedef uint64_t ogg_uint64_t;
           ^
../include/ogg/os_types.h:77:12: error: unknown type name 'uint32_t'
   typedef uint32_t ogg_uint32_t;
           ^
../include/ogg/os_types.h:79:12: error: unknown type name 'uint64_t'
   typedef uint64_t ogg_uint64_t;
           ^
3 errors generated.
make[2]: *** [test_bitwise-bitwise.o] Error 1

I'm not sure at this moment which all systems are affected.

[iEFdev]

I bumped into this one as well (10.7.5).

Attaching the log, if needed.

[kencu (Ken)]

In adaa6d40867ec12e0df5cd5d4003b93e408c9727/macports-ports (master):

libogg: fix build on older systems

it appears stdint.h needs to be explicitly included
for some older systems.
closes: #58924

[kencu (Ken)]

So that patch fixes the builds. Haven't tried PPC yet, hopefully will work there too.

I don't fully understand what the difference was with 10.9+ headers that this is not needed there though -- somehow the extra definitions make it in with including just <sys/types.h> on 10.9+ without this extra header being specifically added...

Happy to learn what changed, if anyone knows -- there could always be a more elegant fix.

[jmroot (Joshua Root)]

Including sys/types.h is certainly not guaranteed to get you those types. This is an upstream bug.

Reference:

• ​https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_types.h.html
• ​https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

[cjones051073 (Chris Jones)]

I agree. Upstream should just include stdint.h irrespective of the OS version.

[kencu (Ken)]

why is it working on newer systems without the patch?

[cjones051073 (Chris Jones)]

something else must be indirectly including it. or the compiler is automatically doing it. Either way, the safe thing to do is include it yourself.

[cjones051073 (Chris Jones)]

just to add, this is not the first time I have run into issues like this. Different compilers having different implicitly included headers. The only correct thing is to include whatever you use....

[jmroot (Joshua Root)]

Commit that broke it: ​https://git.xiph.org/?p=ogg.git;a=commitdiff;h=6449883ccacfee276ed9d99fa047342cdc51ab88

[jmroot (Joshua Root)]

Replying to cjones051073:

just to add, this is not the first time I have run into issues like this. Different compilers having different implicitly included headers. The only correct thing is to include whatever you use....

Different compilers and different libc headers. Depending on the way a header's functionality is implemented, it may (or may not) end up including some other headers.

[kencu (Ken)]

From a practical point of view, the more older systems work exactly like newer systems, the better for us all. If we can figure out what Apple tweaked in the 10.9+ headers to make this work without the patch, it would be a consideration to do that same tweak in legacysupport rather that fix dozens of ports...

Selling the stdint.h change back upstream will obviously be nearly impossible...

[cjones051073 (Chris Jones)]

Selling the stdint.h change back upstream will obviously be nearly impossible...

It shouldn't be.... Its a general coding principle that if you use something from a header, you should include it rather than assume it is done for you...

[jmroot (Joshua Root)]

What Apple did was #include <stdint.h>or the equivalent in some header that is included by sys/types.h because they needed it for some internal reason. Why will it be impossible to sell the use of a header that is the standard way to get these type definitions according to both Posix and C standards?

[kencu (Ken)]

Well some libogg dev specifically changed it away from <stdint.h> to <sys/types.h> to fix a problem, and it works on every system from 10.9+... so that's a tough sell to go back now.

What Apple did was #include <stdint.h>or the equivalent in some header that is included by sys/types.h because they needed it for some internal reason.

Exactly what I suspect.

[cjones051073 (Chris Jones)]

Replying to kencu:

Well some libogg dev specifically changed it away from <stdint.h> to <sys/types.h> to fix a problem, and it works on every system from 10.9+... so that's a tough sell to go back now.

Ah, but that is not what they did. They changed it from

#include <inttypes.h>

to

#include <sys/types.h>

that is not the same thing.

If they are assuming sys/types.h automatically includes it, then extending the above to

#include <stdint.h>
#include <sys/types.h>

would be a no-op on 10.9+, and should fix things on older platforms.

[kencu (Ken)]

Now it looks like this has more widespread repercussions. Software built against libogg is failing, even on 10.14, with stdint related errors.

They'll have to revert this change. In the meantime, we'll probably have to patch it ourselves...

see 58929

[ken-cunningham-webuse]

In f1acabfd8c3133b5bb10d3f4299937b8a9485842/macports-ports (master):

libogg: revert upstream patch

the change in header broke the build on older systems
and broke builds on newer systems as well

closes: #58933
closes: #58929
see: #58924

[jmroot (Joshua Root)]

Replying to cjones051073:

Replying to kencu:

Well some libogg dev specifically changed it away from <stdint.h> to <sys/types.h> to fix a problem, and it works on every system from 10.9+... so that's a tough sell to go back now.

Ah, but that is not what they did. They changed it from

#include <inttypes.h>

to

#include <sys/types.h>

that is not the same thing.

True – inttypes.h defines a bunch of unrelated macros, but unlike sys/types.h, it is guaranteed to include stdint.h.

[jmroot (Joshua Root)]

​https://gitlab.xiph.org/xiph/ogg/issues/2294#note_51544

[jmroot (Joshua Root)]

FTR, upstream went with changing the types used rather than changing the include back: ​https://github.com/xiph/ogg/commit/c8fca6b4a02d695b1ceea39b330d4406001c03ed

[kencu (Ken)]

I find in the software world the best way to get outcome B is to suggest outcome A.

And that's only very slight tongue-in-cheek :>