#67144 closed defect (fixed)
Change to Clang fallback has broken multiple R ports: /bin/sh: /opt/local/bin/clang-mp-14: No such file or directory
Reported by: | barracuda156 | Owned by: | barracuda156 |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.8.1 |
Keywords: | Cc: | cjones051073 (Chris Jones) | |
Port: |
Description
Example of the port which has built fine earlier (this is a trivial update to it):
DEBUG: Executing org.macports.destroot (R-rlecuyer) 11189 DEBUG: Environment: 11190 CC_PRINT_OPTIONS='YES' 11191 CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_R_R-rlecuyer/R-rlecuyer/work/.CC_PRINT_OPTIONS' 11192 CPATH='/opt/local/include' 11193 DEVELOPER_DIR='/Library/Developer/CommandLineTools' 11194 LIBRARY_PATH='/opt/local/lib' 11195 MACOSX_DEPLOYMENT_TARGET='11.0' 11196 SDKROOT='/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk' 11197 Executing: cd "/opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_R_R-rlecuyer/R-rlecuyer/work/rlecuyer" && /opt/local/bin/R CMD INSTALL . --library=/opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_R_R-rlecuyer/R-rlecuyer/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library 11198 DEBUG: system: cd "/opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_R_R-rlecuyer/R-rlecuyer/work/rlecuyer" && /opt/local/bin/R CMD INSTALL . --library=/opt/local/var/macports/build/_Users_runner_work_macports-ports_macports-ports_ports_R_R-rlecuyer/R-rlecuyer/work/destroot/opt/local/Library/Frameworks/R.framework/Versions/4.2/Resources/library 11199 * installing *source* package ‘rlecuyer’ ... 11200 ** package ‘rlecuyer’ successfully unpacked and MD5 sums checked 11201 ** using staged installation 11202 ** libs 11203 /opt/local/bin/clang-mp-14 -I"/opt/local/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -fPIC -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX11.sdk -arch x86_64 -c RngStream.c -o RngStream.o 11204 /bin/sh: /opt/local/bin/clang-mp-14: No such file or directory 11205 make: *** [RngStream.o] Error 127 11206 ERROR: compilation failed for package ‘rlecuyer’
There are some other identical failures here: https://github.com/macports/macports-ports/actions/runs/4515567748/jobs/7953004414 (not all failures are related to this, but several are).
Change History (9)
comment:1 Changed 20 months ago by barracuda156
comment:2 Changed 20 months ago by barracuda156
Summary: | Something recent has broken multiple R ports via Clang choice: /bin/sh: /opt/local/bin/clang-mp-14: No such file or directory → Change to Clang fallback has broken multiple R ports: /bin/sh: /opt/local/bin/clang-mp-14: No such file or directory |
---|
comment:3 follow-up: 4 Changed 20 months ago by jmroot (Joshua Root)
Cc: | cjones051073 added |
---|---|
Component: | base → ports |
It looks to me like the R ports are always building with clang-14, which must be hardcoded or baked in somewhere, and ignoring the value of configure.cc.
comment:4 Changed 20 months ago by barracuda156
Replying to jmroot:
It looks to me like the R ports are always building with clang-14, which must be hardcoded or baked in somewhere, and ignoring the value of configure.cc.
I am not 100% sure, but I think it was due to compilers PG settings for Clangs (or related PG). If now it is moved to Clang-15, then it should be used, perhaps.
I revbumped R
in the PR now: https://github.com/macports/macports-ports/pull/18079
If Clang-15 is picked for it, then it will be saved into Makevars settings, and everything gonna work as before, but with a new Clang. If not, then perhaps hardcoding is the way to go.
I believe, there is nothing inherent in R
itself or its ports that requires a specific Clang version. Some R
packages want C+17, and majority want at least C+11, but both worked with Clang-14 on x86, and should work now with Clang-15, provided it gets picked for R
itself.
comment:5 follow-up: 6 Changed 20 months ago by jmroot (Joshua Root)
OK, so it's baked into R. If that can't be avoided or overridden, you need to make sure that all the R-* ports set the same configure.compiler as R itself.
comment:6 Changed 20 months ago by barracuda156
Replying to jmroot:
OK, so it's baked into R. If that can't be avoided or overridden, you need to make sure that all the R-* ports set the same configure.compiler as R itself.
Everything works conditional on consistent Macports settings. R
revbump solves the problem, CI now pass. I will add a note into clang_compilers to revbump R
port if settings there are changed again. Then we would not run into breaking a 1000+ ports.
comment:7 Changed 20 months ago by barracuda156
Owner: | set to barracuda156 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:8 Changed 20 months ago by cjones051073 (Chris Jones)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
The above commit is not a fix. It is at best a bandaid around what is the real issue, which is R baking the compiler it uses to be built into itself for downstream use.
If this is the case, then the R port needs to be updated to exercise its own control over the compiler it uses, and not just rely on whatever fallback the framework picks for it, as this will on occasion change as default versions get bumped.
comment:9 Changed 20 months ago by Chris Jones <jonesc@…>
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Okay, this: [347cd6ba812a9831a4728c5d61328718bb96e8e5/macports-ports]