> On 13 Feb 2019, at 09:07, Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote:
>
> On Sat, Jul 21 2018, Christopher Zimmermann <chr...@openbsd.org
> <mailto:chr...@openbsd.org>> wrote:
>> On 2018-06-21 Christopher Zimmermann <chr...@openbsd.org> wrote:
>>> Hi,
>>>
>>> the last few days I prepared an update of ocaml to 4.06 and opam to
>>> 2.00rc2 and along with it updates or REVISION bumps of the dependent
>>> ports.
>>
>> Here comes a reworked diff to upgrade to OCaml 4.07. (attached gzipped)
>> Thanks for the testing and fixes you supplied so far.
>> I believe I included all of them so far.
>> I will need some help in moving sysutils/dune to devel/, because I
>> imported it into the wrong category.
>> Also building dune on sparc64 was broken. I suspect the stack size
>> needs to be increased with ulimit -s 8192. Can someone with access to
>> sparc64 please test this as I don't have access to any sparc64 machine?
>
> So, back to this:
> - sysutils/dune has been moved to devel/dune, updated to the latest
> version, which also fixes the stack exhaustion seen on amd64 by krw
> and me.
> - devel/dune is still broken on sparc64 because the "custom bytecode
> executable" produced by dune are stripped by the install target.
> My first idea was just to force dune to produce standard bytecode
> executables. That would be more convenient for the ports tree, but
> ignoring the choices made upstream. We could also just ensure that
> all the ports using dune don't using strip(1).
OCaml bytecode executables prefer -custom mode since that also
supports loading in shared library stubs automatically. If the executable
were built without -custom, it needs setting ld path variables and
matching the right version of ocamlrun.
A reasonable default is to strip native code binaries and not do so for
any bytecode executables built by the OCaml ports (not just the ones
built with dune).
Anil
