error: typedef redefinition with different types

[Ryan Carsten Schmidt]

At least on macOS 12.3.1 with Apple clang version 13.0.0 (clang-1300.0.29.30), ode 0.16.3 does not build:

In file included from timer.cpp:177:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:39:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/LaunchServices.h:23:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Headers/IconsCore.h:23:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/OSServices.h:29:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/OSServices.framework/Headers/CSIdentity.h:43:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:28:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Security.framework/Headers/SecCertificate.h:50:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Security.framework/Headers/cssmtype.h:29:
/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:51:18: error: typedef redefinition with different types ('uint64_t' (aka 'unsigned long long') vs 'duint64' (aka 'unsigned long'))
typedef uint64_t uint64;
                 ^
./typedefs.h:39:17: note: previous definition is here
typedef duint64 uint64;
                ^
1 error generated.

ode 0.16.2 does not have this problem and builds successfully.

[Oleh Derevenko]

That’s bad if system headers spoil global namespace with such type names. One day they can define any other type we choose and we can never be safe.
It would be good if you could report this to the Security Framework developers so that they hide their internal symbols into a namespace or give them some uncommon name (e.g. a name starting with underscore).

[Oleh Derevenko]

Could you please try compiling having the include wrapped with #define and #undef like this?

#define uint64 _uint64
#include <CoreServices/CoreServices.h>
#undef uint64

‌

[Ryan Carsten Schmidt]

Thanks, your suggestion does work. Another solution (which is the one I’ve now used when updating the MacPorts ode port to version 0.16.3) is the one used in MacPorts to fix the opendx software in 2008:

https://trac.macports.org/ticket/14085

which is to define _UINT64, _UINT32, _UINT16, and _UINT8 to let the system headers know you have defined these types.

It seems the interference of the uint64 type due to the Security Framework is a very old problem.

Here is a report of this problem encountered with ocaml on Mac OS X 10.5 (2007) and 10.6 (2009):

https://github.com/ocaml/ocaml/issues/4877

Here is a report of this problem encountered with libtiff on Mac OS X 10.7 (2011):

https://gitlab.com/libtiff/libtiff/-/issues/51

I will leave it to you to file a bug report with Apple and argue your case with them if you wish, but it seems unlikely that they would change it now, and even if they did, they might consider it to be a breaking change and thus would not publish it until the next major version of macOS (version 14, due out later this year) and thus would be of no help to users of the decades worth of earlier macOS releases, so I recommend you work around the problem in your software.

https://feedbackassistant.apple.com

[Oleh Derevenko]

So, was it the only one name conflict or did you redefine some other types as well?

[Oleh Derevenko]

I’m asking because of your mentioning of the _UINT32, _UINT16, _UINT8…