Building camlpdf.top fails

[glondu]

Hi,

When updating the Debian package from 2.4 to 2.5.3, I get the following error:

[...]
ocamlmktop \
			  \
			 flatestubs.o rijndael-alg-fst.o stubs-aes.o sha2.o stubs-sha2.o        -g  -ccopt -Wl,-z,relro      -o camlpdf.top \
			pdfutil.cmo pdfio.cmo pdftransform.cmo pdfunits.cmo pdfpaper.cmo pdfcryptprimitives.cmo pdf.cmo pdfcrypt.cmo pdfflate.cmo pdfcodec.cmo pdfwrite.cmo pdfgenlex.cmo pdfread.cmo pdfjpeg.cmo pdfops.cmo pdfdest.cmo pdfmarks.cmo pdfpagelabels.cmo pdfpage.cmo pdfannot.cmo pdffun.cmo pdfspace.cmo pdfimage.cmo pdfafm.cmo pdfafmdata.cmo pdfglyphlist.cmo pdftext.cmo pdfstandard14.cmo pdfgraphics.cmo pdfshapes.cmo pdfdate.cmo pdfocg.cmo pdfcff.cmo pdftype1.cmo pdftruetype.cmo pdfmerge.cmo
File "_none_", line 1:
Error: Error while linking pdfcryptprimitives.cmo:
       The external function `camlpdf_caml_sha512' is not available
make[2]: *** [OCamlMakefile:966: camlpdf.top] Error 2
[...]

[johnwhitington]

Is this using a Debian-patched version of OCaml? Could you try with a vanilla opam install of OCaml instead as a first step?

[glondu]

Yes. Actually, the problem comes from building with NO_CUSTOM=y. However, without it, camlpdf.cma has the Force custom flag on... I've disabled building the toplevel for the time being.

[johnwhitington]

Is there anything for me to fix here? Is this an OCamlmakefile problem? Are these flags new in recent versions of OCaml?

[glondu]

An OCamlMakefile problem, I would say.

-custom has an history, which I can summarize (from memory) as follows:

• binaries built with -custom and pristine ocaml cannot be stripped, because the stripping process removes the bytecode and leaves only the runtime in the binary, making it mostly useless
• I've made a patch to ocaml, and applied it in Debian, to adopt a different strategy for -custom compatible with strip
• I've submitted said patch to upstream, who rejected it on the grounds that -custom is deprecated and should no longer be used

This is why the package is built with NO_CUSTOM=y.

By the way, #load-ing camlpdf in the standard toplevel (or utop) seems to work. I do not see the value of building camlpdf.top.

[johnwhitington]

Thanks for the explanation. I've removed the building of camlpdf.top, and I'll leave this bug open to remind me to have another think about -custom for the next release.