Building OCaml 4.02.3 on macOS Big Sur

Ecosystem
,
1

Anybody know why I might be having trouble building 4.02.3 on macOS? I’m trying to pick back up a project that’s languished for a year or so; I have an opam-lockfile with all my dependencies, but I’m having trouble replicating my configuration in 2021, lol.

I’m getting Fatal error: exception Invalid_argument("inet_addr_of_string not implemented"); here’s the full log:

https://asciinema.org/a/384460

[ERROR] The compilation of ocaml-base-compiler failed at "/Users/ec/.opam/opam-init/hooks/sandbox.sh build make world.opt".

#=== ERROR while compiling ocaml-base-compiler.4.02.3 =========================#
# context     2.0.7 | macos/x86_64 |  | https://opam.ocaml.org#5484ff3c
# path        ~/Sync/Code/excmd/packages/bs-excmd/_opam/.opam-switch/build/ocaml-base-compiler.4.02.3
# command     ~/.opam/opam-init/hooks/sandbox.sh build make world.opt
# exit-code   2
# env-file    ~/.opam/log/ocaml-base-compiler-57653-d2c37b.env
# output-file ~/.opam/log/ocaml-base-compiler-57653-d2c37b.out
### output ###
# [...]
# ../boot/ocamlrun ../ocamlc -nostdlib -I ../stdlib -pp './remove_DEBUG' -I ../parsing -I ../utils -I ../typing -I ../driver -I ../bytecomp -I ../tools -I ../toplevel/ -I ../stdlib -I ../otherlibs/str -I ../otherlibs/dynlink -I ../otherlibs/unix -I ../otherlibs/num -I ../otherlibs/graph -warn-error A -safe-string -c generators/odoc_literate.ml
# /Library/Developer/CommandLineTools/usr/bin/make manpages
# mkdir -p stdlib_man
# sh ./runocamldoc false -man -d stdlib_man -I ../parsing -I ../utils -I ../typing -I ../driver -I ../bytecomp -I ../tools -I ../toplevel/ -I ../stdlib -I ../otherlibs/str -I ../otherlibs/dynlink -I ../otherlibs/unix -I ../otherlibs/num -I ../otherlibs/graph \
# 	-t "OCaml library" -man-mini \
# 	../stdlib/*.mli ../parsing/*.mli ../otherlibs/unix/unix.mli ../otherlibs/str/str.mli ../otherlibs/bigarray/bigarray.mli ../otherlibs/num/num.mli
# Fatal error: exception Invalid_argument("inet_addr_of_string not implemented")
# make[4]: *** [stdlib_man/Pervasives.3o] Error 2
# make[3]: *** [all] Error 2
# make[2]: *** [ocamldoc] Error 2
# make[1]: *** [opt.opt] Error 2
# make: *** [world.opt] Error 2
1 Like
2

It seems that somehow the configuration script decided that sockets were not supported by your OS. Could you link the whole opam log (aka the output-file)?

3

Meta-level note: 4.02.3 was published in July 2015, so we don’t expect it to work that well with newer toolchains / C compilers which introduce new warnings/errors/behaviors on a semi-regular basis.

Lockfiles can produce an illusion of stability if they lock a fixed OCaml environment on top of a moving system.

Ideally I would recommend either updating OCaml to more recent versions from time to time, to avoid this issue (but then one may have to deal with possibly updates to the OCaml dependencies, when the locked versions for some reason do not support a recent OCaml release). Another approach is to use an actually-stable system environment such as a container image or a Nix/Guix-style system.

1 Like
4

Maybe totally wrong. There is a thing happening with ocaml versions and there was patch that seems to fix this for me. See exn: `Sys.getcwd not implemented` for ocaml 4.6.100 and probably others · Issue #1177 · esy/esy · GitHub

1 Like
5

Yeah, it’s not an, uh, ideal situation — I’m a (sometimes?) BuckleScript guy, and we were already stuck on a really old version when I stepped away from this work.

In fact, the lockfile in this case isn’t intending to future-proof things in the usual way of a lockfile / containerization; it was actually there to document/enforce two nominally-incompatible versions of dependencies which, in fact, where the only versions that would work together. Altogether a nightmare. I’m very apprehensive about attempting to resurrect this fragile nightmare from the grave, heh.

Holy shit, that is actually the same problem! Yeah, an opam update fixed it entirely; it looks like it was that same issue fixed in opam-repository#17379: Fix OCaml < 4.08.0 for XCode 12. I wouldn’t have come across that without your help, thank you! <3

2 Likes
7

The configure part of the log is unfortunately missing. However, I had forgotten that clang has switched to -fno-common by default too. So your problem might be that you have a stale 4.02.3 opam package without the -fcommon patch. You could try to update it.