#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)
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
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: | new → closed |
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: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 follow-up: 12 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:11 Changed 5 years ago by jmroot (Joshua Root)
Commit that broke it: https://git.xiph.org/?p=ogg.git;a=commitdiff;h=6449883ccacfee276ed9d99fa047342cdc51ab88
comment:12 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 follow-up: 14 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 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 follow-up: 17 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 follow-up: 20 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.
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 revert this change. In the meantime, we'll probably have to patch it ourselves...
see 58929
comment:19 Changed 5 years ago by ken-cunningham-webuse
comment:20 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:21 Changed 5 years ago by jmroot (Joshua Root)
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 :>
I bumped into this one as well (10.7.5).
Attaching the log, if needed.