Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#41280 closed defect (fixed)

tiff @4.0.3_1: redefinition of uint64

Reported by: mojca (Mojca Miklavec) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Schmidt), titus@…, cooljeanius (Eric Gallager)
Port: tiff

Description (last modified by mojca (Mojca Miklavec))

Compilation of hugin-app is broken because libtiff redefines uint64. The error is:

/opt/local/include/tiff.h:78:23: error: typedef redefinition with different types ('unsigned long' vs 'uint64_t' (aka 'unsigned long long'))
typedef TIFF_UINT64_T uint64;
                      ^
//System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:51:18: note: previous definition is here
typedef uint64_t uint64;
                 ^
1 warning generated.
1 warning and 1 error generated.

Here's a complete log from the buildbot: https://build.macports.org/builders/buildports-mtln-x86_64/builds/9524

My temporary workaround was to put

// typedef TIFF_UINT64_T uint64;
typedef uint64_t uint64;

into tiff.h which made hugin-app compile successfully, but I'm aware that this is probably not a proper solution.

I submitted an upstream bug report here:

Attachments (1)

tiff-datatypes-configure.ac.diff (3.6 KB) - added by mojca (Mojca Miklavec) 6 years ago.
a patch for tiff data types during configuration phase

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by mojca (Mojca Miklavec)

Description: modified (diff)

comment:2 Changed 6 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

See also #38168.

comment:3 Changed 6 years ago by mojca (Mojca Miklavec)

Cc: titus@… added

There is actually at least one more problem: the currently generated tiffconf.h won't work properly with universally built libtiff.

comment:4 Changed 6 years ago by mojca (Mojca Miklavec)

Is my attachment something in the direction of what Titus had in mind on the mailing list (I have no idea how to patch ssize_t and pointer sizes though)? (One could actually avoid the configure phase altogether. Just hardcode everything.)

Yet untested.

Changed 6 years ago by mojca (Mojca Miklavec)

a patch for tiff data types during configuration phase

comment:5 Changed 6 years ago by titus@…

Yes, your patch looks like what I suggested.

I don't think that there's a need to patch much more than necessary. Or why would you want to patch the definitions of ssize_t and the like?

Could you elaborate on "one more problem" with the "universally built" libtiff?

Is this problem caused by the patch or is it something similar but unrelated?

comment:6 Changed 6 years ago by mojca (Mojca Miklavec)

Cc: egall@… added

comment:7 Changed 6 years ago by mojca (Mojca Miklavec)

Here's a minimal example to reproduce the problem:

#include <ApplicationServices/ApplicationServices.h>
#include <tiffio.h>

int main() { return 0; }

which fails to compile in the same way:

> g++ test.cpp -o test -I/opt/local/include
In file included from /opt/local/include/tiffio.h:33,
                 from test.cpp:2:
/opt/local/include/tiff.h:78: error: conflicting declaration ‘typedef long unsigned int uint64’
/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:53: error: ‘uint64’ has a previous declaration as ‘typedef uint64_t uint64’

comment:8 in reply to:  5 Changed 6 years ago by mojca (Mojca Miklavec)

Replying to titus@…:

Or why would you want to patch the definitions of ssize_t and the like?

No reason other than having a fear that it might lead to similar weird errors in other contexts.

Could you elaborate on "one more problem" with the "universally built" libtiff?

Compiling:

#include <tiffio.h>

int main()
{
  uint64 a;
  printf("%d\n", sizeof(a));
  return 0;
}

with

g++ -arch i386 test.cpp -o test -I/opt/local/include

results in

./test
4

while it should return 8.

Is this problem caused by the patch or is it something similar but unrelated?

The patch should correct this wrong behaviour (but I'm not saying that my proposed patch is the best possible solution - it should probably be refined a bit).

comment:9 Changed 6 years ago by mojca (Mojca Miklavec)

I committed r113360. If anyone opposes or has anything to add, feel free to change it.

I tried to come up with as minimal patch as possible which would solve the immediate problem. This should be fixed properly upstream, ideally avoiding the int64 type altogether.

comment:10 Changed 6 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: newclosed

comment:11 Changed 6 years ago by mojca (Mojca Miklavec)

See also #39934.

Note: See TracTickets for help on using tickets.