[MacPorts] #39934: camlimages @4.0.1_7: build failure
MacPorts
noreply at macports.org
Fri Dec 20 00:48:23 PST 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
More information about the macports-tickets
mailing list