Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
Hi,
Ping? As Ian mentioned earlier, without this series it is not possible
to build Xen tools for ARM64 in osstest.
Cheers,
On 02/08/2017 07:50 PM, Julien Grall wrote:
Hi,
On 24/01/17 22:19, David Scott wrote:
On 24 Jan 2017, at 11:35, Ian Jackson wrote:
Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
ocamlopt"):
Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.
...
This does not actually fix the real problem. I'm unsure how to fix it
properly, for the following reasons:
Can I have some input from ocaml folks ?
The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.
ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'. However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.
I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where
`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable itself
Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.
I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
(therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
to either.
The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).
I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
directly to *.cmxa files which are native-code only— I don’t see how that
could work for bytecode outputs.
Do you have a link to the build failure?
Here a link for the build failure:
http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
(Resending the e-mail due to SMTP issue)
On 02/14/2017 02:18 PM, Julien Grall wrote:
Hi,
Ping? As Ian mentioned earlier, without this series it is not possible
to build Xen tools for ARM64 in osstest.
Cheers,
On 02/08/2017 07:50 PM, Julien Grall wrote:
Hi,
On 24/01/17 22:19, David Scott wrote:
On 24 Jan 2017, at 11:35, Ian Jackson
wrote:
Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness
when no ocamlopt"):
Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.
...
This does not actually fix the real problem. I'm unsure how to fix it
properly, for the following reasons:
Can I have some input from ocaml folks ?
The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.
ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'. However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.
I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`?
Where
`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable
itself
Both `ocamlc` and `ocamlc.opt` should be interchangeable: same
command-line
arguments, exactly the same output. Same for `ocamlopt` and
`ocamlopt.opt`.
I _think_ the m4 is looking for `ocamlc.opt` because it’s an
optimised native
(therefore faster) version of `ocamlc`. It should be fine to set
`OCAMLC`
to either.
The tools/ocaml/Makefile.rules does contain rules for both bytecode
outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe
*.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).
I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it
refers
directly to *.cmxa files which are native-code only— I don’t see how
that
could work for bytecode outputs.
Do you have a link to the build failure?
Here a link for the build failure:
http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
Hi,
On 24/01/17 22:19, David Scott wrote:
>
>> On 24 Jan 2017, at 11:35, Ian Jackson wrote:
>>
>> Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
>> ocamlopt"):
>>> Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
>>> package lacks ocamlopt.
>> ...
>>> This does not actually fix the real problem. I'm unsure how to fix it
>>> properly, for the following reasons:
>>
>> Can I have some input from ocaml folks ?
>>
>> The first ARM64 boxes in the Xen Project test lab are in principle now
>> online, but this bug is stopping osstest actually getting as far as
>> trying to boot Xen.
>>
>>> ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
>>> `ocamlc'. However our ocaml Makefiles seem to explicitly call
>>> $(OCAMLOPT) in some places and and $(OCAMLC) in others.
>
> I’m terrible at reading m4 and am really bad with autoconf so I may have
> got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where
>
> `ocamlc`: outputs bytecode, and is a bytecode executable itself
> `ocamlc.opt`: outputs bytecode, and is a native code executable itself
> `ocamlopt`: outputs native code, and is a bytecode executable itself
> `ocamlopt.opt`: outputs native code, and is a native code executable itself
>
> Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
> arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.
>
> I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
> (therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
> to either.
>
> The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
> (e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
> can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).
>
> I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
> directly to *.cmxa files which are native-code only— I don’t see how that
> could work for bytecode outputs.
>
> Do you have a link to the build failure?
Here a link for the build failure:
http://logs.test-lab.xenproject.org/osstest/logs/105644/build-arm64/5.ts-xen-build.log
Cheers,
--
Julien Grall
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
> On 24 Jan 2017, at 11:35, Ian Jackson wrote:
>
> Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
> ocamlopt"):
>> Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
>> package lacks ocamlopt.
> ...
>> This does not actually fix the real problem. I'm unsure how to fix it
>> properly, for the following reasons:
>
> Can I have some input from ocaml folks ?
>
> The first ARM64 boxes in the Xen Project test lab are in principle now
> online, but this bug is stopping osstest actually getting as far as
> trying to boot Xen.
>
>> ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
>> `ocamlc'. However our ocaml Makefiles seem to explicitly call
>> $(OCAMLOPT) in some places and and $(OCAMLC) in others.
I’m terrible at reading m4 and am really bad with autoconf so I may have
got this wrong but does it set OCAMLC to `ocamlopt` or `ocamlc.opt`? Where
`ocamlc`: outputs bytecode, and is a bytecode executable itself
`ocamlc.opt`: outputs bytecode, and is a native code executable itself
`ocamlopt`: outputs native code, and is a bytecode executable itself
`ocamlopt.opt`: outputs native code, and is a native code executable itself
Both `ocamlc` and `ocamlc.opt` should be interchangeable: same command-line
arguments, exactly the same output. Same for `ocamlopt` and `ocamlopt.opt`.
I _think_ the m4 is looking for `ocamlc.opt` because it’s an optimised native
(therefore faster) version of `ocamlc`. It should be fine to set `OCAMLC`
to either.
The tools/ocaml/Makefile.rules does contain rules for both bytecode outputs
(e.g. *.cmo *.cma) and native code outputs (*.cmx *.cmxa). I believe *.cmi
can be created by either ocamlc (ocamlc.opt) or ocamlopt (ocamlopt.opt).
I’m a bit suspicious of the tools/ocaml/xenstored/Makefile where it refers
directly to *.cmxa files which are native-code only— I don’t see how that
could work for bytecode outputs.
Do you have a link to the build failure?
Thanks,
Dave
>>
>> Simply changing tools/ocaml/common.make to substitute the variables
>> from their corresponding autoconf names seems like it isn't right.
>>
>> Our Makefiles explicitly call ocamlc via OCAMLC right now even when
>> ocamlopt is available, and substituting OCAML would change those calls
>> to OCAMLOPT. And it wouldn't help fix the actual build failure,
>> either, because if there is no ocamlopt, the m4 doesn't provide a
>> useful OCAMLOPT.
>>
>> FYI the ocamlforge m4 comes with a pod. You can get it from
>> https://forge.ocamlcore.org/anonscm/git/ocaml-autoconf/ocaml-autoconf.git
>>
>> I haven't copied that into xen.git in patch 1/2. Should I ?
>> In the meantime, a formatted copy is below.
>
> Ian.
>
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
Ian Jackson writes ("[PATCH 0/2] ocaml: Start on fixing brokenness when no
ocamlopt"):
> Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
> package lacks ocamlopt.
...
> This does not actually fix the real problem. I'm unsure how to fix it
> properly, for the following reasons:
Can I have some input from ocaml folks ?
The first ARM64 boxes in the Xen Project test lab are in principle now
online, but this bug is stopping osstest actually getting as far as
trying to boot Xen.
> ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
> `ocamlc'. However our ocaml Makefiles seem to explicitly call
> $(OCAMLOPT) in some places and and $(OCAMLC) in others.
>
> Simply changing tools/ocaml/common.make to substitute the variables
> from their corresponding autoconf names seems like it isn't right.
>
> Our Makefiles explicitly call ocamlc via OCAMLC right now even when
> ocamlopt is available, and substituting OCAML would change those calls
> to OCAMLOPT. And it wouldn't help fix the actual build failure,
> either, because if there is no ocamlopt, the m4 doesn't provide a
> useful OCAMLOPT.
>
> FYI the ocamlforge m4 comes with a pod. You can get it from
> https://forge.ocamlcore.org/anonscm/git/ocaml-autoconf/ocaml-autoconf.git
>
> I haven't copied that into xen.git in patch 1/2. Should I ?
> In the meantime, a formatted copy is below.
Ian.
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH 0/2] ocaml: Start on fixing brokenness when no ocamlopt
Debian jessie arm64 has Ocaml (in the package `ocaml-nox') but the
package lacks ocamlopt.
This causes xen.git builds to fail. Our configure script detects that
ocaml is available. Our version of m4/ocaml.m4 sort of tries to
figure out what the best compiler is but only does have the job. And
then our tools/ocaml/common.make unconditionally uses ocamlopt.
I am not sure exactly how to fix this (see below) but I think these
two patches are an essential start:
1/2 ocaml: Copy up-to-date m4/ocaml.m4 from forge.ocamlcore
2/2 ocaml: Substitute tools/ocaml/common.make with configure
(An alternative for 1/2 would be a git merge, which would provide the
docs and git history and so on - but the ocaml-autoconf README seems
to expetus to copy the m4 into our own project.)
This does not actually fix the real problem. I'm unsure how to fix it
properly, for the following reasons:
ocaml.m4 expects to set OCAMLC to either `ocamlopt' or failing that
`ocamlc'. However our ocaml Makefiles seem to explicitly call
$(OCAMLOPT) in some places and and $(OCAMLC) in others.
Simply changing tools/ocaml/common.make to substitute the variables
from their corresponding autoconf names seems like it isn't right.
Our Makefiles explicitly call ocamlc via OCAMLC right now even when
ocamlopt is available, and substituting OCAML would change those calls
to OCAMLOPT. And it wouldn't help fix the actual build failure,
either, because if there is no ocamlopt, the m4 doesn't provide a
useful OCAMLOPT.
FYI the ocamlforge m4 comes with a pod. You can get it from
https://forge.ocamlcore.org/anonscm/git/ocaml-autoconf/ocaml-autoconf.git
I haven't copied that into xen.git in patch 1/2. Should I ?
In the meantime, a formatted copy is below.
Ian.
IO::FILE=IO(0X834C450)User Contributed Perl DocumentaIO::FILE=IO(0X834C450)(1)
NAME
ocaml.m4 - Autoconf macros for OCaml
SUMMARY
AC_PROG_OCAML
AC_PROG_FINDLIB
AC_PROG_OCAMLLEX
AC_PROG_OCAMLYACC
AC_PROG_CAMLP4
AC_CHECK_OCAML_PKG([name])
AC_CHECK_OCAML_MODULE(VARIABLE,NAME,MODULE,INCLUDE-PATHS)
AC_CHECK_OCAML_WORD_SIZE
DESCRIPTION
ocaml.m4 is a file containing standard, useful autoconf macros for
detecting the OCaml, findlib, OCaml packages, and so on in your
autoconf-generated ./configure scripts.
To begin using these macros, you will need to copy the "ocaml.m4" file
(usually located at "/usr/share/aclocal/ocaml.m4") to the autoconf
macros directory in your project. Normally this is the "m4/" directory
in your project, but the directory can be changed using the
"AC_CONFIG_MACRO_DIR(DIR)" directive. If you have just created the
"m4/" directory, then you may also need to do:
aclocal -I m4
You can then add any of the macros described below to your
"configure.ac" (or "configure.in"). Almost every OCaml project should
use "AC_PROG_OCAML" first and probably "AC_PROG_FINDLIB" right after
it.
This manual page does not describe how to use autoconf. For that you
should read the detailed autoconf info file ("info autoconf").
AC_PROG_OCAML
This macro detects which tools of the usual OCaml toolchain are
available. It defines and substitutes the following variables:
OCAMLC set to the name of the bytecode compiler
(eg. "ocamlc" or "ocamlc.opt"), or "no" if
no OCaml installation was found
OCAMLOPTthe name of the native-code compiler, eg. "ocamlopt",
"ocamlopt.opt" or "no"
OCAMLBEST "byte" (if only the bytecode compiler is available)
or "opt" (if both bytecode and native code compilers
are available)
OCAMLNATDYNLINK "yes" (if native dynlink is available) or "no"
OCAMLDEPthe name of the dependency resolver, eg. "ocamldep"
OCAMLMKTOP the name of ocamlmktop
OCAMLMKLIB the name of ocamlmklib
OCAMLDOCthe name of ocamldoc
OCAMLBUILD the name of ocamlbuild
OCAMLLIBthe OCaml library path (eg. C)
OCAMLVERSIONthe compiler version (eg. C<3.11.0>)
Detecting if OCaml is installed
Unlike old versions of these macros, "AC_PROG_OCAML" does not exit if
no OCaml installation is detected. Therefore if you want to detect if
OCaml is installed you have to do something like this:
AC_PROG_OCAML
if test "$OCAMLC" = "no"; then
AC_MSG_ERROR([You must install the OCaml compiler])
fi
This behaviour and usage pattern are consistent with other macros of
the "AC_PROG_*") family.
Cross-compiling
If the configure script is invoked for cross-compiling then
"AC_PROG_OCAML" will detect the cross-compiler versions of the OCaml
compiler, eg. "OCAMLC=i68
