redefined data types in different packages - request for help

Mojca Miklavec mojca at macports.org
Mon Nov 11 11:08:39 PST 2013


On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote:
> Hi Mojca,
>
> since this beautiful example of Bad Code (TM) is inside (system) library
> headers there's not much you can do without reporting upstream

http://bugzilla.maptools.org/show_bug.cgi?id=2464

> or resorting
> to very rude measures like using your own patched tiff:

MacPorts sometimes fixes upstream bugs in order to make the ports
compile. This would probably be another such case. The problem is that
I'm not sure how to properly fix this in tiff.

> Without having a system here to test my suggestions, you might be able to
> - configure tiff to not define this type name (or define it correctly in the
> sense of portability and compatibility, at least).

I cannot configure it to not define the type name "uint64". This type
name is used all over the place. The solution might be to define it to
uint64_t instead of "unsigned long".

> - configure the software to try to avoid #including one or the other file
> (WTH is cssmconfig.h, anyway?)

The file cssmconfig.h is part of Security.framework. What it is used
for - no idea at all.

Mojca


More information about the macports-dev mailing list