Thu 15 Nov 2012 04:15:35 PM UTC, original submission:
version: 0.9.3
OS version: 10.8.x (probably 10.7, too)
tl;dr Could you remove or guard three lines in the stdint.mini.h so that UINT64_T, _UINT32_T and _UINT8_T are _not defined on OS X? See attached patch.
### Into
Since Apple started to remove the compiler toolchain from a freshly installed OS X, Homebrew supports building software with the toolchain provided by Xcode. This toolchain is not located at /usr but at some other (longer path).
### configure
Therefore stdint.h and others are not at /usr/include but at /Applications/Xcode.app/.../usr/include. Configure reports HAVE_STDINT_H = 1 but I saw some hard coded /usr/include/stdint.h tests. Not sure here. But that's not the point. Homebrew adds via the --sysroot switch the correct path and indeed the stdint.h is found successfully.
### stdint.mini.h
However the stdint.mini.h of libunistring seems to define some stuff before the system's stdint.h is included and especially defines _UINT64_T and so the uint64_t from the system's stdint.h is no longer defined (there is a `#ifndef`).
### Possible Solution
Libunistring does no typedef but defines the macro like so:
/* Avoid collision with Solaris 2.5.1 <pthread.h> etc. */
#define _UINT8_T
#define _UINT32_T
#define _UINT64_T
For homebrew, I just removed these three and the build succeeds.
### Question
Could you remove or guard these lines so they are not defined on OS X ?
Or do you think something other went wrong and the stdint.mini.h should not have been used in the first place (on OS X)?
How can I tell libunistring to use the stdint.h from OS X? (The compiler finds it but the local ./stdint.h takes precedence)
|