3.0.2: "Error: exception End_of_file" for all builds on OpenBSD #5471
Description
Expected Behavior
dune build raises no exceptions.
Actual Behavior
$ dune build
Error: exception End_of_file
Raised at Stdlib.input_line.scan in file "stdlib.ml", line 456, characters
14-31
Called from Dune_config.auto_concurrency.loop in file
"src/dune_config/dune_config.ml", line 416, characters 22-35
Called from Dune_config.auto_concurrency in file
"src/dune_config/dune_config.ml", line 422, characters 14-27
Called from CamlinternalLazy.force_lazy_block in file "camlinternalLazy.ml",
line 31, characters 17-27
Re-raised at CamlinternalLazy.force_lazy_block in file "camlinternalLazy.ml",
line 36, characters 4-11
Called from Dune_config.for_scheduler in file
"src/dune_config/dune_config.ml", line 430, characters 14-41
Called from Main__import.Scheduler.go in file "bin/import.ml", line 130,
characters 17-65
Called from Cmdliner_term.app.(fun) in file
"vendor/cmdliner/src/cmdliner_term.ml", line 25, characters 19-24
Called from Cmdliner.Term.run in file "vendor/cmdliner/src/cmdliner.ml", line
117, characters 32-39
Called from Cmdliner.Term.term_eval in file
"vendor/cmdliner/src/cmdliner.ml", line 147, characters 18-36
Called from Cmdliner.Term.Group.eval in file
"vendor/cmdliner/src/cmdliner.ml", line 367, characters 22-48
Called from Main in file "bin/main.ml", line 90, characters 10-50
I must not crash. Uncertainty is the mind-killer. Exceptions are the
little-death that brings total obliteration. I will fully express my cases.
Execution will pass over me and through me. And when it has gone past, I
will unwind the stack along its path. Where the cases are handled there will
be nothing. Only I will remain.
Reproduction
- run
dune buildwith Dune 3.0.2 on OpenBSD
Specifications
- Version of
dune(output ofdune --version):3.0.2
- Version of
ocaml(output ofocamlc --version)4.13.1
- Operating system (distribution and version):
OpenBSD 7.0 GENERIC.MP#5 amd64
Additional information
My reading of Dune_config.auto_concurrency.loop suggests the following is happening:
- check
PATHfornproc, not found - check
PATHforgetconf, finds/usr/bin/getconf - calls
getconf _NPROCESSORS_ONLN - OpenBSD responds with
- standard error:
getconf: _NPROCESSORS_ONLN: unknown variable - standard output: none
- exit 1
- standard error:
input_lineraisesEnd_of_filebecause standard output was empty
I'm glad to test and submit a patch if you can point me in the direction you'd prefer. My inclination would be to replace:
let n = input_line ic |> String.trim |> Int.of_string inwith something like
let n = try input_line ic |> String.trim |> Int.of_string with _ -> 1since the process exits 1, the subsequent pattern for WEXITED 0 should cause n = 1 to be ignored and continue on with getconf NPROCESSORS_ONLN which works on this platform.
Verbose output (run dune with the --verbose flag) is identical to the backtrace above, but starts with
Shared cache: disabled
Workspace root: /home/michael/conf/src/ocaml
Dune 3.0.02 on Linux 5.15.16-0-lts #1-Alpine SMP x86_64 Linux builds this repository without problems.
Dune 2.9.3 on this OpenBSD machine and this repository also builds fine.
In the future, I'd be glad to test Dune release candidates on OpenBSD to help catch these things earlier. I don't usually follow Dune's trunk development closely.
By the way, kudos for the Dune reference 😉