[MacPorts] #60793: kremlin-devel: cc1: error: unrecognized command line option "-std=c11"
MacPorts
noreply at macports.org
Tue Jul 7 16:29:50 UTC 2020
#60793: kremlin-devel: cc1: error: unrecognized command line option "-std=c11"
----------------------------+----------------------
Reporter: ryandesign | Owner: landonf
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.6.2
Resolution: | Keywords:
Port: kremlin-devel |
----------------------------+----------------------
Comment (by landonf):
> This suggests that the port isn't UsingTheRightCompiler (isn't actually
using clang 9)
>
> It's impossible to tell because the build appears to be using silent
rules (please disable that if possible)
These are both symptoms of the same problem; the kremlin compiler (krml)
generates C and directly drives the C compiler to compile it, but doesn't
support specifying an alternative path to the C compiler. You can only
specify the compiler family via `-cc <clang|gcc|compcert|g++|msvc>`; krml
searches PATH for a corresponding (hard-coded) compiler binary name.
I have a work-around (which I don't particularly love) based on adding a
bunch of compiler symlinks to the `build.env` `PATH`. My other thought was
to patch krml to invoke the MacPorts compiler using an absolute path
(requiring a runtime dependency on said compiler), but I've been wary of
diverging significantly from upstream behavior.
What I might do is leave the existing behavior and compiler family
definitions as-is, but patch krml to add a new, non-default "mp-clang"
compiler family that uses an absolute path to MacPorts' clang. By
explicitly passing `-cc mp-clang` when building the port, the port will
build with the right compiler, but users depending on krml's PATH-based
compiler discovery won't have their builds broken.
--
Ticket URL: <https://trac.macports.org/ticket/60793#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list