Open leana8959 opened 4 weeks ago
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
?)
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 :)
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?
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)
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.
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 :)
I tried to install
dune
. However, this failed with the aforementioned error.I opened an issue at https://github.com/ocaml/dune/issues/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:
Specifications
dune
(output ofdune --version
): 3.14.2ocaml
(output ofocamlc --version
): 4.12.1Output of
opam config report
Thank you :)