Re: 4.04 changes
On 03/03/2017 14:19, Ximin Luo wrote:
I've pushed the changes to the debian/experimental branch. It builds well but fails here:
Looking at the commit diff, I suspect the package won't build on
bytecode architectures. For example, it unconditionally installs
ocamlopt.*. You should try on a porterbox.
dh_ocaml -Xcompiler-libs \
--runtime-map ocaml-nox:ocaml-base-nox,ocaml:ocaml-base \
--checksum 4.04.0
Fatal error: cannot find file 'tools/objinfo'
E: Error running OCAMLLIB=tools boot/ocamlrun tools/objinfo on debian/ocaml-nox/usr/bin/ocamlc.byte
I can fix this by doing this:
diff --git a/debian/rules b/debian/rules
index 0c7f4c03..fccd038a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -47,7 +47,7 @@ endif
endif
# Environment variable for dh_ocaml
-export OCAMLOBJINFO = OCAMLLIB=tools boot/ocamlrun tools/objinfo
+export OCAMLOBJINFO = OCAMLLIB=tools debian/tmp/usr/bin/ocamlobjinfo
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
I would have fixed the argument to boot/ocamlrun instead
(tools/ocamlobjinfo instead of tools/objinfo).
Indeed, your patch works on native because
debian/tmp/usr/bin/ocamlobjinfo is a symlink to the native,
self-contained, ELF-executable ocamlobjinfo.opt. But on bytecode, it
will be a symlink to the bytecode executable ocamlobjinfo.byte which
cannot run on its own since ocamlrun is not yet installed. The simplest
fix IMHO is to always use the bytecode one, with an explicit call to
ocamlrun.
Then the build succeeds and I get some .debs, but there are lots of warnings:
dh_ocaml -Xcompiler-libs \
--runtime-map ocaml-nox:ocaml-base-nox,ocaml:ocaml-base \
--checksum 4.04.0
W: ocaml-nox/ocaml-base-nox v4.04.0-1 doesn't resolve dependency on unit Optmain
W: ocaml-nox/ocaml-base-nox v4.04.0-1 doesn't resolve dependency on unit Flambda
W: ocaml-nox/ocaml-base-nox v4.04.0-1 doesn't resolve dependency on unit Cmm
W: ocaml-nox/ocaml-base-nox v4.04.0-1 doesn't resolve dependency on unit Typedecl
etc, about 150-200 of them.
Is it OK to ignore, or should I fix the build failure in some other way?
It looks OK to ignore here. But I'm not saying that these warnings
should be ignored in general! For example, and I suspect it is the case
here, you'll get one such warning for each private module of the
compiler that is not installed. It means you won't be able to dynload
modules depending on them, but it's fine as long as these modules are
meant to be loaded only in the toplevel interpreter (where these private
modules are linked in).
Thank you for working on this!
Cheers,
--
Stéphane
Reply to: