0

I tried to install the package camlidl in a new Ubuntu 22 virtual machine with the usual OCaml package install command:

$ opam install camlidl.1.12

But I got the following error message, which I had never seen before:

[ERROR] The compilation of camlidl.1.12 failed at "make all".

#=== ERROR while compiling camlidl.1.12 =======================================#

context 2.1.2 | linux/x86_64 | ocaml.4.13.1 | https://opam.ocaml.org#28c3ca4d

path ~/.opam/default/.opam-switch/build/camlidl.1.12

command ~/.opam/opam-init/hooks/sandbox.sh build make all

exit-code 1

env-file ~/.opam/log/camlidl-513510-e00e41.env

output-file ~/.opam/log/camlidl-513510-e00e41.out

output

bwrap: execvp make: No such file or directory

I had successfully installed this same package in other Ubuntu 22 virtual machines running under the same host machine before, so I found it odd that this time the opam install command had failed.

The error message also seemed strange to me, since my system does have make available in its standard location ( /usr/bin/make ) and I can successfully build/compile all my C++ projects that depend on "make" in this very same system with no problem.

What could we wrong this time?

1 Answers1

0

[Solution]

Turns out that the OcamL Package Manager (opam) creates a "sandboxed" build environment when installing packages with help of the "BubbleWrap" utility (bwrap). One side effect of using the bwrap utility is that it will ignore and reject any command that is not directly available in the host file system to provide its functional "sanboxed" isolated build environment.

In my new Ubuntu 22 virtual machine I am testing a new release of the make command, whose repository resides in a separate mount point (i.e., another hard drive) and I had created a "soft link" to the compiled new release from the standard make bin location as such:

sudo ln -s /mnt/otherdrive/source/gnu/make/make /usr/bin/make

So in the end, bwrap made the Ocaml build environment ignore/be blind to my local make command since the binary being pointed to is located in a separate filesystem.

One solution would be to recreate the link to the make command as a "hard link" instead, but "hard links" cannot be created among different file systems.

Therefore, my solution was to eliminate the soft link and copy the make binary directly into its standard location (/usr/bin/make).

sudo rm /usr/bin/make
sudo cp -p /mnt/otherdrive/source/gnu/make/make /usr/bin/make

I hope this helps other users facing similar problems when installing packages or libraries that rely on internally creating "sandboxed environments" that can temporarily hide/block access to normally working build utilities and commands.