Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#58924 closed defect (fixed)

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

Reported by: kencu (Ken) Owned by: kencu (Ken)
Priority: Normal Milestone:
Component: ports Version:
Keywords: lion snowleopard Cc: cjones051073 (Chris Jones)
Port: libogg

Description (last modified by 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.

Attachments (2)

libogg-fail-SL.log (19.7 KB) - added by kencu (Ken) 5 years ago.
libogg_(Lion)_main.log (21.4 KB) - added by iEFdev 5 years ago.

Download all attachments as: .zip

Change History (25)

Changed 5 years ago by kencu (Ken)

Attachment: libogg-fail-SL.log added

comment:1 Changed 5 years ago by kencu (Ken)

Description: modified (diff)

comment:2 Changed 5 years ago by iEFdev

I bumped into this one as well (10.7.5).

Attaching the log, if needed.

Changed 5 years ago by iEFdev

Attachment: libogg_(Lion)_main.log added

comment:3 Changed 5 years ago by kencu (Ken)

Keywords: lion added

comment:4 Changed 5 years ago by kencu (Ken)

Owner: set to kencu
Resolution: fixed
Status: newclosed

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

comment:5 Changed 5 years ago by 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.

comment:6 Changed 5 years ago by jmroot (Joshua Root)

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

Reference:

comment:7 Changed 5 years ago by cjones051073 (Chris Jones)

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

comment:8 Changed 5 years ago by kencu (Ken)

why is it working on newer systems without the patch?

comment:9 Changed 5 years ago by 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.

comment:10 Changed 5 years ago by 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....

comment:12 in reply to:  10 Changed 5 years ago by 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.

comment:13 Changed 5 years ago by 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...

comment:14 in reply to:  13 Changed 5 years ago by 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...

comment:15 Changed 5 years ago by 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?

comment:16 Changed 5 years ago by 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.

comment:17 in reply to:  16 ; Changed 5 years ago by 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.

Last edited 5 years ago by cjones051073 (Chris Jones) (previous) (diff)

comment:18 Changed 5 years ago by 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 rever this change. In the meantime, we'll probably have to patch it ourselves...

see 58929

Version 0, edited 5 years ago by kencu (Ken) (next)

comment:19 Changed 5 years ago by 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

comment:20 in reply to:  17 Changed 5 years ago by 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.

comment:22 Changed 5 years ago by jmroot (Joshua Root)

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

comment:23 Changed 5 years ago by 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 :>

Note: See TracTickets for help on using tickets.