Opened 9 years ago

Closed 3 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 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)

main.log (54.8 KB) - added by jaredwmoore@… 9 years ago.
Log file of failure

Download all attachments as: .zip

Change History (15)

Changed 9 years ago by jaredwmoore@…

Attachment: main.log added

Log file of failure

comment:1 Changed 9 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 failedcamlimages @4.0.1_7: build failure

Thanks for the ticket. In the future, please Cc relevant port maintainers (port info --maintainers).

comment:2 Changed 9 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 9 years ago by MartinBuchmann (Martin Buchmann)

Cc: Martin.Buchmann@… added

Cc Me!

comment:4 Changed 9 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

Last edited 9 years ago by MartinBuchmann (Martin Buchmann) (previous) (diff)

comment:5 Changed 9 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:6 Changed 9 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
Last edited 9 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:7 Changed 9 years ago by larryv (Lawrence Velázquez)

Cc: mojca@… added

comment:8 Changed 9 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 9 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 9 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

Markus, any comment or solution for this possible ocaml issue? It prevents camlimages from building.

comment:11 Changed 7 years ago by kurthindenburg (Kurt Hindenburg)

Owner: changed from reilles@… to macports-tickets@…

comment:12 Changed 4 years ago by pmetzger (Perry E. Metzger)

Owner: changed from macports-tickets@… to pmetzger
Status: newassigned

comment:13 Changed 3 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: MarcusCalhoun-Lopez added

comment:14 Changed 3 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Resolution: fixed
Status: assignedclosed

In a555a381ec1cbce7ef8236e7fe5cf38162434a4e/macports-ports (master):

camlimages: update version 4.0.1->4.2.6

Fixes #39934
Fixes #56187

Note: See TracTickets for help on using tickets.