fatal error: CoreFoundation/CoreFoundation.h: No such file or directory

[leana8959]

I tried to install dune. However, this failed with the aforementioned error.

I opened an issue at ocaml/dune#10394, and I was recommended to come here. Please tell me if there's a more relevant place for this problem!

Expected Behavior

Dune installs correctly.

Actual Behavior

Dune doesn't install correctly with the error src/fsevents/fsevents_stubs.c:15:10: fatal error: CoreFoundation/CoreFoundation.h: No such file or directory.

This happens with dune 3.6.0 and 3.14.2.

Here's the error log:

# context     2.1.5 | macos/arm64 |  | https://opam.ocaml.org#3ae17654
# path        ~/univ-repos/skeletons/necro/_opam/.opam-switch/build/dune.3.14.2
# command     ~/.opam/opam-init/hooks/sandbox.sh build ocaml boot/bootstrap.ml -j 9
# exit-code   2
# env-file    ~/.opam/log/dune-2492-ab7007.env
# output-file ~/.opam/log/dune-2492-ab7007.out
### output ###
# ocamlc -output-complete-exe -w -24 -g -o .duneboot.exe -I boot unix.cma boot/libs.ml boot/duneboot.ml
# ./.duneboot.exe -j 9
# cd _boot && /Users/leana/univ-repos/skeletons/necro/_opam/bin/ocamlopt.opt -c -g -I +threads fsevents_stubs.c
# src/fsevents/fsevents_stubs.c:15:10: fatal error: CoreFoundation/CoreFoundation.h: No such file or directory
# compilation terminated.
#

Specifications

• Version of dune (output of dune --version): 3.14.2
• Version of ocaml (output of ocamlc --version): 4.12.1
• Operating system (distribution and version): Darwin 23.4.0, macOS 14.4.1

Output of opam config report

# opam config report
# opam-version         2.1.5 
# self-upgrade         no
# system               arch=arm64 os=macos os-distribution=homebrew os-version=14.4.1
# solver               builtin-mccs+glpk
# install-criteria     -removed,-count[avoid-version,changed],-count[version-lag,request],-count[version-lag,changed],-count[missing-depexts,changed],-changed
# upgrade-criteria     -removed,-count[avoid-version,changed],-count[version-lag,solution],-count[missing-depexts,changed],-new
# jobs                 9
# repositories         1 (http), 1 (version-controlled) (default repo at 3ae17654)
# pinned               0
# current-switch       /Users/leana/univ-repos/skeletons/necro
# ocaml:native         true
# ocaml:native-tools   true
# ocaml:native-dynlink true
# ocaml:stubsdir       /Users/leana/univ-repos/skeletons/necro/_opam/lib/ocaml/stublibs:/Users/leana/univ-repos/skeletons/necro/_opam/lib/ocaml
# ocaml:preinstalled   false
# ocaml:compiler       4.12.1

Thank you :)

[dra27]

Clutching at straws slightly, could we have a bit more information about your build environment.... do you have any additional or non-standard C compilers installed (in particular, what's the output of which -a clang?)

[leana8959]

Thanks for your reply !

$ which -a clang
/usr/bin/clang

$ clang --version
Apple clang version 15.0.0 (clang-1500.3.9.4)
Target: arm64-apple-darwin23.4.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

It seems like I have Apple's clang in my path. I do have nix installed and gnugcc installed with it.

$ which gcc
/run/current-system/sw/bin/gcc

$ gcc --version
gcc (GCC) 12.3.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I know that by default, macOS comes with gcc as an alias to clang. Is there a simple way to tell opam to use clang so that I could debug if the issue is caused by it using gcc instead of clang ?

Thanks :)

[leana8959]

Update:
I removed gcc from nix, and it worked. Thanks !

Although I don't know the internals of opam, maybe it's a good idea to invoke clang directly on macOS in the build scripts so that this kind of situation don't happen?

[dra27]

Ah, thanks! From opam's perspective, this duplicates ocaml/opam#5784. However, I'm wondering if we should harden something in OCaml itself here (and trying to remember if we've discussed it before)

[dra27]

I can't remember/find whether this has been discussed, but I'm wondering if we should unconditionally tweak the name of the C compiler on macOS builds (in order to stop this from happening) or at least provide an ability for opam to stop this from happening. It seems reasonable that we should correctly select the toolchain, or at least have some way for something like Dune to determine (from ocamlc -config etc.) if this is supposed to be Xcode or actual gcc, etc.

[leana8959]

I'm wondering if we should unconditionally tweak the name of the C compiler on macOS builds (in order to stop this from happening) or at least provide an ability for opam to stop this from happening.

I think it would be a nice thing to have ! Since having the wrong compiler gives really generic error messages that are unrelated, it's quite hard to debug.

I think the issue you were talking about might be ocaml/opam#601, however, this issue is not dedicated to the "gcc on macOS" problem. Would it be more adequate to follow the aforementioned issue for updates or create a new issue specifically for this situation ?

Thanks again :)