Re: [MacPorts] #39934: camlimages @4.0.1_7: build failure

20 Dec 2013

      #39934: camlimages @4.0.1_7: build failure
----------------------------+-----------------------
  Reporter:  jaredwmoore@…  |      Owner:  reilles@…
      Type:  defect         |     Status:  new
  Priority:  Normal         |  Milestone:
 Component:  ports          |    Version:  2.2.0
Resolution:                 |   Keywords:
      Port:  camlimages     |
----------------------------+-----------------------

Comment (by mojca@…):

 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.

-- 
Ticket URL: <https://trac.macports.org/ticket/39934#comment:8>
MacPorts <http://www.macports.org/>
Ports system for OS X