#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 Carsten 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)
Change History (12)
comment:1 Changed 11 years ago by mojca (Mojca Miklavec)
Description: | modified (diff) |
---|
comment:2 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|
comment:3 Changed 11 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 11 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 11 years ago by mojca (Mojca Miklavec)
Attachment: | tiff-datatypes-configure.ac.diff added |
---|
a patch for tiff data types during configuration phase
comment:5 follow-up: 8 Changed 11 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 11 years ago by mojca (Mojca Miklavec)
Cc: | egall@… added |
---|
comment:7 Changed 11 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 Changed 11 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 11 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 11 years ago by mojca (Mojca Miklavec)
Resolution: | → fixed |
---|---|
Status: | new → closed |
See also #38168.