I’ve just created a fresh switch for OCaml 4.14.1 (opam switch create 4.14.1). Now I want to install Dune in order to build an existing project, but attempting to install fails with no informative output:
$ opam install dune
The following actions will be performed:
∗ install dune 3.7.0
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><> 🐫
⬇ retrieved dune.3.7.0 (cached)
[ERROR] The compilation of dune.3.7.0 failed at "ocaml boot/bootstrap.ml -j 7".
#=== ERROR while compiling dune.3.7.0 =========================================#
# context 2.1.1 | macos/x86_64 | ocaml-base-compiler.4.14.1 | https://opam.ocaml.org#b26ac460
# path ~/.opam/4.14.1/.opam-switch/build/dune.3.7.0
# command ~/.opam/opam-init/hooks/sandbox.sh build ocaml boot/bootstrap.ml -j 7
# exit-code 255
# env-file ~/.opam/log/dune-64362-4462fc.env
# output-file ~/.opam/log/dune-64362-4462fc.out
### output ###
# ocamlc -output-complete-exe -w -24 -g -o .duneboot.exe -I boot unix.cma boot/libs.ml boot/duneboot.ml
<><> Error report <><><><><><><><><><><><><><><><><><><><><><><><><><><><><> 🐫
┌─ The following actions failed
│ λ build dune 3.7.0
└─
╶─ No changes have been performed
The mentioned .out file just repeats the ocamlc invocation, and has no other content. I’d appreciate any suggestions on how I can figure out what actually broke the build.
It’s likely that opam left a directory ~/.opam/4.14.1/.opam-switch/build/dune.3.7.0, from which you can run the same command by hand, but with a bit more debugging:
ocamlc -verbose -output-complete-exe -w -24 -g -o .duneboot.exe -I boot unix.cma boot/libs.ml boot/duneboot.ml
Hopefully this will give you a bit more info on what is going wrong.
You may have to call opam install with --keep-build-dir to have what @vlaviron suggests.
Also could you give us the output of opam config report just to see if there’s nothing fishy.
Thanks! this works, but the output is less than ideal:
~/.opam/4.14.1/.opam-switch/build/dune.3.7.0 $ ocamlc -verbose -output-complete-exe -w -24 -g -o .duneboot.exe -I boot unix.cma boot/libs.ml boot/duneboot.ml
[1] 59848 segmentation fault ocamlc -verbose -output-complete-exe -w -24 -g -o .duneboot.exe -I boot
Which system package managers do you use ? Do you have binutils or gcc installed in one of these and in your PATH ? That is was OCaml really compiled against the MacOS C toolchain (xcode) ?
Is there anything I could try completely resetting short of nuking my opam installation? (I have other switches I need, and this was literally a fresh switch created after an opam update)
I use homebrew. gcc and binutils (XCode-provided) are both on my path, and haven’t previously been an issue.
I’m not totally sure how to answer your last question. Here’s the console output from building the switch:
$ opam switch create 4.14.1
<><> Installing new switch packages <><><><><><><><><><><><><><><><><><><><> 🐫
Switch invariant: ["ocaml-base-compiler" {= "4.14.1"} | "ocaml-system" {= "4.14.1"}]
<><> Processing actions <><><><><><><><><><><><><><><><><><><><><><><><><><> 🐫
∗ installed base-bigarray.base
∗ installed base-threads.base
∗ installed base-unix.base
∗ installed ocaml-options-vanilla.1
⬇ retrieved ocaml-base-compiler.4.14.1 (cached)
∗ installed ocaml-base-compiler.4.14.1
∗ installed ocaml-config.2
∗ installed ocaml.4.14.1
Done.
First things first can you compile a hello world program ?
> eval $(opam env --switch=4.14.1)
> echo 'let () = print_endline "hello"' > hello.ml
> ocamlc -verbose -output-complete-exe -w -24 -g -o hello hello.ml
> ./hello
Ah, apparently not! I get a segfault when compiling your hello world program as well. Basic things like ocamlc --help don’t segfault.
Could you give the output of the following sequence of operations
> opam switch 4.14.1
> eval $(opam env)
> env
> type ld
> type cc
> ocamlc -config
Stripping out a couple sensitive non-OCaml-related bits from env (after ensuring it’s on the switch as directed):
$ env
LC_TERMINAL_VERSION=3.4.12
COLORFGBG=15;0
ITERM_PROFILE=Default
XPC_FLAGS=0x0
LANG=en_US.UTF-8
PWD=/Users/csg63/research/InhabitationLambdaBang
SHELL=/bin/zsh
__CFBundleIdentifier=com.googlecode.iterm2
SECURITYSESSIONID=186a4
TERM_PROGRAM_VERSION=3.4.12
TERM_PROGRAM=iTerm.app
PATH=/Users/csg63/.opam/4.14.1/bin:/Users/csg63/.jenv/shims:/Users/csg63/.jenv/bin:/usr/local/opt/ruby/bin:/Users/csg63/.opam/default/bin:/usr/local/bin:/Users/csg63/.elan/bin:/Users/csg63/.cargo/bin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin:/usr/local/share/dotnet:~/.dotnet/tools:/Library/Apple/usr/bin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/colingordon/.dotnet/tools:/Users/csg63/.dotnet/tools:/Users/csg63/Library/Application Support/Coursier/bin
LC_TERMINAL=iTerm2
COLORTERM=truecolor
COMMAND_MODE=unix2003
TERM=xterm-256color
HOME=/Users/csg63
USER=csg63
XPC_SERVICE_NAME=0
LOGNAME=csg63
LaunchInstanceID=E31233A2-A845-4B95-A92B-6375E8E28A09
__CF_USER_TEXT_ENCODING=0x0:0:0
SHLVL=1
OLDPWD=/Users/csg63/.opam/4.14.1/.opam-switch/build/dune.3.7.0
ZSH=/Users/csg63/.oh-my-zsh
PAGER=less
LESS=-R
LSCOLORS=Gxfxcxdxbxegedabagacad
OPAMNOENVNOTICE=true
OPAM_SWITCH_PREFIX=/Users/csg63/.opam/4.14.1
CAML_LD_LIBRARY_PATH=/Users/csg63/.opam/4.14.1/lib/stublibs:/Users/csg63/.opam/4.14.1/lib/ocaml/stublibs:/Users/csg63/.opam/4.14.1/lib/ocaml
OCAML_TOPLEVEL_PATH=/Users/csg63/.opam/4.14.1/lib/toplevel
JENV_SHELL=zsh
JENV_LOADED=1
_=/usr/bin/env
$ type ld
ld is /usr/bin/ld
$ type cc
cc is /usr/bin/cc
$ ocamlc -config
version: 4.14.1
standard_library_default: /Users/csg63/.opam/4.14.1/lib/ocaml
standard_library: /Users/csg63/.opam/4.14.1/lib/ocaml
ccomp_type: cc
c_compiler: cc
ocamlc_cflags: -O2 -fno-strict-aliasing -fwrapv -pthread
ocamlc_cppflags: -D_FILE_OFFSET_BITS=64
ocamlopt_cflags: -O2 -fno-strict-aliasing -fwrapv -pthread
ocamlopt_cppflags: -D_FILE_OFFSET_BITS=64
bytecomp_c_compiler: cc -O2 -fno-strict-aliasing -fwrapv -pthread -D_FILE_OFFSET_BITS=64
native_c_compiler: cc -O2 -fno-strict-aliasing -fwrapv -pthread -D_FILE_OFFSET_BITS=64
bytecomp_c_libraries: -lm -lpthread
native_c_libraries: -lm
native_pack_linker: ld -r -o
architecture: amd64
model: default
int_size: 63
word_size: 64
system: macosx
asm: cc -c -Wno-trigraphs
asm_cfi_supported: true
with_frame_pointers: false
ext_exe:
ext_obj: .o
ext_asm: .s
ext_lib: .a
ext_dll: .so
os_type: Unix
default_executable_name: a.out
systhread_supported: true
host: x86_64-apple-darwin22.2.0
target: x86_64-apple-darwin22.2.0
flambda: false
safe_string: true
default_safe_string: true
flat_float_array: true
function_sections: false
afl_instrument: false
windows_unicode: false
supports_shared_libraries: true
naked_pointers: true
exec_magic_number: Caml1999X031
cmi_magic_number: Caml1999I031
cmo_magic_number: Caml1999O031
cma_magic_number: Caml1999A031
cmx_magic_number: Caml1999Y031
cmxa_magic_number: Caml1999Z031
ast_impl_magic_number: Caml1999M031
ast_intf_magic_number: Caml1999N031
cmxs_magic_number: Caml1999D031
cmt_magic_number: Caml1999T031
linear_magic_number: Caml1999L031
We once lost a significant amount of hours with this kind of setup, see here.
Though I can’t see CLICOLOR_FORCE in your env. Could you maybe try to see if doing things in a regular POSIX sh helps – I doubt, but let’s remove that uncertainty.
(I have to go I may be available later)
Not sure if this is relavant here, but you know that this gcc is not really gcc, right?
It’s a clang cc just named gcc to fool installers.
This is my platform too: Mac OSX (Big Sur), amd64, Ocaml 4.14.1. It does work for me. How recent or not is the Xcode?
I get the same failure regardless of shell.
I’m aware that gcc on macos is just an alias for clang. I updated it relatively recently:
$ gcc --version
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
I’m using the most recent version of XCode (or at least, the command line tools, I don’t install the full XCode system, just what you get with xcode-select --install)
I’m also running Intel, macOS Ventura.
I used homebrew to upgrade my system ocaml to 4.14.0 (from 4.10), and opam to 2.1.4 (from 2.1.1) and observe the same results.
Best option here is probably to look for existing issues and file a new issue in the dune repo.
It is not a dune issue since a simple « hello world » program can’t compile.
I ran a bit out of ideas, the next thing I would do is to run that segfaulting ocamlc invocation with lldb -- … to see where that happens.