Opened 11 years ago
Closed 5 years ago
#39934 closed defect (fixed)
camlimages @4.0.1_7: build failure
Reported by: | jaredwmoore@… | Owned by: | pmetzger (Perry E. Metzger) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | MartinBuchmann (Martin Buchmann), cooljeanius (Eric Gallager), mojca (Mojca Miklavec), mww@…, ryandesign (Ryan Carsten Schmidt), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) | |
Port: | ocaml, camlimages |
Description
Error: org.macports.build for port camlimages returned: command execution failed
OSX Version 10.6.8
XCode Version 4.0.2
Log file seems to indicate that the error arises due to redefinitions of typedef 'int64' and 'uint64' in tiff.h and the config.h for caml while trying to make the tiffwrite.o object file. Trouble starts around line 898-907 of the attached log file.
Attachments (1)
Change History (15)
Changed 11 years ago by jaredwmoore@…
comment:1 Changed 11 years ago by larryv (Lawrence Velázquez)
Keywords: | typedef removed |
---|---|
Owner: | changed from macports-tickets@… to reilles@… |
Port: | camlimages added |
Summary: | camlimages @4.0.1 Build error: command execution failed → camlimages @4.0.1_7: build failure |
Thanks for the ticket. In the future, please Cc relevant port maintainers (port info --maintainers
).
comment:2 Changed 11 years ago by devernay (Frédéric Devernay)
The camlimages source can easily be patched to fix that by including tiff in a different way, see #38168 and https://github.com/Itseez/opencv/commit/33c26a93c6d97013b14e7dd080a347e242ef7f37
comment:3 Changed 11 years ago by MartinBuchmann (Martin Buchmann)
Cc: | Martin.Buchmann@… added |
---|
Cc Me!
comment:4 Changed 11 years ago by MartinBuchmann (Martin Buchmann)
I am still having the same problem on OS X 10.9.1, Xcode 5.02, using clang instead of gcc. Is there any news about when the patches regarding tiff etc. will be applied?
Regards
Martin
comment:6 Changed 11 years ago by cooljeanius (Eric Gallager)
mojca committed r113360 to try to solve this and #41280 and #38168, but at least here that does not seem to have worked... Also in my build log it complains about redefinitions of int16 and uint16, in addition to the ones mentioned in the OP:
+ /usr/bin/gcc-4.2 -I /usr/include/X11 -I /usr/local/include -I/opt/local/include/freetype2 -fPIC -I /opt/local/lib/ocaml -I/usr/include/X11 -I/usr/local/include -MM xpmwrite.c tiffwrite.c:24:1: warning: "int16" redefined In file included from /opt/local/lib/ocaml/caml/mlvalues.h:18, from tiffwrite.c:18: /opt/local/lib/ocaml/caml/compatibility.h:309:1: warning: this is the location of the previous definition tiffwrite.c:25:1: warning: "uint16" redefined /opt/local/lib/ocaml/caml/compatibility.h:310:1: warning: this is the location of the previous definition In file included from /opt/local/include/tiffio.h:33, from tiffwrite.c:29: /opt/local/include/tiff.h:77: error: conflicting types for ‘int64’ /opt/local/lib/ocaml/caml/config.h:126: error: previous declaration of ‘int64’ was here /opt/local/include/tiff.h:78: error: conflicting types for ‘uint64’ /opt/local/lib/ocaml/caml/config.h:127: error: previous declaration of ‘uint64’ was here
comment:7 Changed 11 years ago by larryv (Lawrence Velázquez)
Cc: | mojca@… added |
---|
comment:8 Changed 11 years ago by mojca (Mojca Miklavec)
The reason why the patch doesn't work for OCaml most probably lies in the fact that its configure
script outputs the following definitions:
if test $2 = 8; then echo "#define ARCH_INT64_TYPE long" >> m.h echo "#define ARCH_UINT64_TYPE unsigned long" >> m.h echo '#define ARCH_INT64_PRINTF_FORMAT "l"' >> m.h int64_native=true else sh ./runtest longlong.c case $? in 0) echo "64-bit \"long long\" integer type found (printf with \"%ll\")." echo "#define ARCH_INT64_TYPE long long" >> m.h echo "#define ARCH_UINT64_TYPE unsigned long long" >> m.h echo '#define ARCH_INT64_PRINTF_FORMAT "ll"' >> m.h int64_native=true;; 1) echo "64-bit \"long long\" integer type found (printf with \"%q\")." echo "#define ARCH_INT64_TYPE long long" >> m.h echo "#define ARCH_UINT64_TYPE unsigned long long" >> m.h echo '#define ARCH_INT64_PRINTF_FORMAT "q"' >> m.h int64_native=true;; 2) echo "64-bit \"long long\" integer type found (but no printf)." echo "#define ARCH_INT64_TYPE long long" >> m.h echo "#define ARCH_UINT64_TYPE unsigned long long" >> m.h echo '#undef ARCH_INT64_PRINTF_FORMAT' >> m.h int64_native=true;; *) echo "No suitable 64-bit integer type found, will use software emulation." echo "#undef ARCH_INT64_TYPE" >> m.h echo "#undef ARCH_UINT64_TYPE" >> m.h echo '#undef ARCH_INT64_PRINTF_FORMAT' >> m.h int64_native=false;; esac fi
which is later being used in
./byterun/config.h:typedef ARCH_UINT64_TYPE uint64;
so yet another redefinition of uint64 (which happened to be "compatible" with tiff before my patch, but of course incompatible with system libraries apart from being plain wrong if OCaml would support being built as +universal
).
I would report the problem upstream and would ask them to use uint64_t
instead of unsigned long long
, but you can also try to fix it here by replacing one with the other. Please try. I'm unable to reproduce the problem on Lion, so I cannot reliably say whether the proposed patch (replacing unsigned long long
with uint64_t
and adding #include <stdint.h>
where necessary) would work.
As for redefinition of (u)int16
, the problem might be the same. In TIFF I only applied the bare minimum patch which made compilation possible. I submitted a bug report to http://bugzilla.maptools.org/show_bug.cgi?id=2464, but it got zero attention from delevopers so far. If there are further problems with other data types, the patch can of course be extended.
If OCaml depends on tiff
directly, the main developers of OCaml might argue that they are unable to fix the issue unless it's also fixed it tiff
, but it would actually be a lot cleaner to simply use uint64_t
all over the place and avoid defining their own data type uint64
altogether. In that case there wouldn't be any conflict anywhere.
Anyway, please report the issue upstream and please try if a proposed local patch helps.
comment:9 Changed 11 years ago by mojca (Mojca Miklavec)
Cc: | mww@… added |
---|---|
Port: | ocaml added |
Version: | 2.2.0 |
I'm sorry, when I said that I was unable to reproduce the problem I meant that ocaml
builds fine. I see now that the problem arises when building camlimages
. Either way I still believe that the problem is in OCaml sources.
After changing /opt/local/lib/ocaml/caml/config.h
:
@@ -14,6 +14,8 @@ #ifndef CAML_CONFIG_H #define CAML_CONFIG_H +#include <stdint.h> + #ifndef __PIC__ # define ARCH_CODE32 #endif @@ -22,8 +24,8 @@ #define SIZEOF_LONG 8 #define SIZEOF_PTR 8 #define SIZEOF_SHORT 2 -#define ARCH_INT64_TYPE long -#define ARCH_UINT64_TYPE unsigned long +#define ARCH_INT64_TYPE int64_t +#define ARCH_UINT64_TYPE uint64_t #define ARCH_INT64_PRINTF_FORMAT "l" #undef ARCH_BIG_ENDIAN #undef ARCH_ALIGN_DOUBLE
the port camlimages
compiles just fine.
(I'm tempted to reassign the owner of the ticket to the OCaml maintainer.)
comment:10 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… added |
---|
Markus, any comment or solution for this possible ocaml issue? It prevents camlimages from building.
comment:11 Changed 9 years ago by kurthindenburg (Kurt Hindenburg)
Owner: | changed from reilles@… to macports-tickets@… |
---|
comment:12 Changed 6 years ago by pmetzger (Perry E. Metzger)
Owner: | changed from macports-tickets@… to pmetzger |
---|---|
Status: | new → assigned |
comment:13 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Cc: | MarcusCalhoun-Lopez added |
---|
comment:14 Changed 5 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Log file of failure