Opened 4 years ago
Closed 4 years ago
#60793 closed defect (fixed)
kremlin-devel: cc1: error: unrecognized command line option "-std=c11"
Reported by: | ryandesign (Ryan Carsten Schmidt) | Owned by: | landonf (Landon Fuller) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.2 |
Keywords: | Cc: | ||
Port: | kremlin-devel |
Description
The kremlin-devel portfile says:
compiler.c_standard 2011
The build log for kremlin-devel says:
DEBUG: Using compiler 'MacPorts Clang 9.0'
and yet:
cc1: error: unrecognized command line option "-std=c11"
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)
Change History (4)
comment:1 follow-up: 3 Changed 4 years ago by landonf (Landon Fuller)
comment:2 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
So krml is built, and used during the build, and it is installed?
The build of kremlin-devel used -std=c11
. Is that unique to the build of kremlin-devel or would anything built by krml do that?
comment:3 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to landonf:
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.
That sucks :) We should probably begin by reporting that bug to the developers so that they can fix it and then we don't have to invent a custom solution for this problem in MacPorts.
comment:4 Changed 4 years ago by landonf (Landon Fuller)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.