Opened 3 months ago
Last modified 3 weeks ago
#71068 new defect
R build fails due to g95 dependency, despite specifying gcc
| Reported by: | klausness | Owned by: | |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.10.2 |
| Keywords: | R g95 | Cc: | kjellpk (Kjell Konis), i0ntempest, barracuda156, fracai, ksshannon (Kyle Shannon), jowens (John Owens), msrski59, szhorvat (Szabolcs Horvát), JDLH (Jim DeLaHunt) |
| Port: | R |
Description
R appears to have a dependency on g95, even though that cannot be built.
This appears to be a recent issue. I had R successfully installed already, and when I tried to upgrade it, macports fetched the g95 distfiles and then gave me a message saying, "building g95 is not supported with Xcode 9 or greater". The R variant I had installed was R @4.4.1_2+aqua+builtin_lapack+cairo+gcc13+openmp+tcltk+x11, which presumably should not depend on g95.
When I tried to uninstall R and then reinstall it with just the +gcc13 variant, I received the message, "g95 is known to fail. Try to install anyway?"
Change History (25)
comment:1 Changed 3 months ago by barracuda156
comment:2 follow-ups: 4 8 Changed 3 months ago by jmroot (Joshua Root)
Why is a good question, but the dependency is definitely there. macOS 14.7 x86_64, Xcode + CLTs 16.0:
% port deps R
Full Name: R @4.4.1_3+aqua+builtin_lapack+cairo+g95+openmp+tcltk+x11
Build Dependencies: pkgconfig, g95, clang-16
Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv,
libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo,
tiff, unzip, xz, zip, zlib, cairo, pango, glib2, freetype,
fontconfig, gettext-runtime, tcl, tk, xorg-libice,
xorg-libsm, xorg-libX11, xorg-libXt, libomp
Runtime Dependencies: clang-16
comment:3 follow-up: 5 Changed 3 months ago by jmroot (Joshua Root)
Note also that the gcc13 variant is not used because it doesn't exist:
% port variants R
R has the variants:
accelerate: build using the BLAS and Lapack in Apple's Accelerate framework
* conflicts with atlas builtin_lapack openblas
[+]aqua: Enable native macOS graphics support, needed by R.app and quartz
variant
atlas: build using the BLAS in the atlas port
* conflicts with accelerate builtin_lapack openblas
[+]builtin_lapack: build using reference BLAS and Lapack
* conflicts with accelerate atlas openblas
[+]cairo: use cairo and pango
debug: build with debug symbols
[+]g95: Build using the g95 Fortran compiler
* conflicts with gccdevel
gccdevel: Build using the MacPorts gcc devel compiler
* conflicts with g95 g95
java: enable Java
latex: build with LaTeX support and docs in PDF
openblas: build using the BLAS and Lapack in the OpenBLAS port
* conflicts with accelerate atlas builtin_lapack
[+]openmp: enable parallelism support using OpenMP
quartz: Enable native macOS graphics support
* conflicts with x11
* requires aqua
[+]tcltk: enable use of tcltk
tests: include tests of R installation
[+]x11: Enable X11 support
* conflicts with quartz
comment:4 Changed 3 months ago by barracuda156
Replying to jmroot:
Why is a good question, but the dependency is definitely there. macOS 14.7 x86_64, Xcode + CLTs 16.0:
% port deps R Full Name: R @4.4.1_3+aqua+builtin_lapack+cairo+g95+openmp+tcltk+x11 Build Dependencies: pkgconfig, g95, clang-16 Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv, libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo, tiff, unzip, xz, zip, zlib, cairo, pango, glib2, freetype, fontconfig, gettext-runtime, tcl, tk, xorg-libice, xorg-libsm, xorg-libX11, xorg-libXt, libomp Runtime Dependencies: clang-16
Looks like whoever was handling Xcode 16 bug, blacklisted gcc13 for it, but did not set the correct alternative, so MacPorts for some reason falls back to a pre-historic g95.
I use Xcode 15 on Sonoma, and as you can see, +gcc13 is correctly picked.
comment:5 follow-up: 7 Changed 3 months ago by klausness
Replying to jmroot:
Note also that the gcc13 variant is not used because it doesn't exist:
Interesting. It certainly did exist (and is still listed on the web docs for the R port), but I guess it must have been removed due to the XCode 16 bug that barracuda156 mentioned.
Unfortunately, the gccdevel variant depends on libgcc-devel, which conflicts with libgcc and libgcc12, which I can't uninstall due to other installed ports depending on them.
comment:6 Changed 3 months ago by fracai
| Cc: | fracai added |
|---|
comment:7 Changed 3 months ago by barracuda156
Replying to klausness:
Replying to jmroot:
Note also that the gcc13 variant is not used because it doesn't exist:
Interesting. It certainly did exist (and is still listed on the web docs for the R port), but I guess it must have been removed due to the XCode 16 bug that barracuda156 mentioned.
Unfortunately, the gccdevel variant depends on libgcc-devel, which conflicts with libgcc and libgcc12, which I can't uninstall due to other installed ports depending on them.
gcc14 should be used with Xcode 16.
comment:8 Changed 3 months ago by barracuda156
Replying to jmroot:
Why is a good question, but the dependency is definitely there. macOS 14.7 x86_64, Xcode + CLTs 16.0:
Ok, so the problem is using Xcode from Sequoia on Sonoma. R port uses conditions based on macOS version: https://github.com/macports/macports-ports/blob/318d93038495b88fcfa618019c0ff52c21ef7f62/math/R/Portfile#L47-L74
So everything works fine with Xcode 15 on Sonoma, but breaks when one installs instead Xcode 16.
- S. The matching condition is in
RPG: https://github.com/macports/macports-ports/blob/318d93038495b88fcfa618019c0ff52c21ef7f62/_resources/port1.0/group/R-1.0.tcl#L106-L133
comment:9 follow-up: 10 Changed 3 months ago by Alex11N
Adding a probably redundant data point, I have exactly the same problem on Sonoma 14.7 using the latest macports (2.10.2), Xcode (16.0) and the CLTs.
macports gcc is 14.2.0_3+stdlib_flag (active); macports llvm suites are: llvm-16 @16.0.6_1 (active), llvm-18 @18.1.8_0 (active). llvm18 rebuilt successfully last night from the latest macports update.
The g95 roadblock is still persistent of course. I made the daft mistake of uninstalling R, so will now have to get the precompiled version from r-projects.org. That also means downloading a whole stack of libraries again. This is all a bit frustrating.
As a final comment, there's absolutely NO WAY that I'm installing 15.0.x Sequoia on this current Mac (2019 19,2 i7 machine).
comment:10 follow-up: 23 Changed 3 months ago by barracuda156
Replying to Alex11N:
Adding a probably redundant data point, I have exactly the same problem on Sonoma 14.7 using the latest macports (2.10.2), Xcode (16.0) and the CLTs.
macports gcc is 14.2.0_3+stdlib_flag (active); macports llvm suites are: llvm-16 @16.0.6_1 (active), llvm-18 @18.1.8_0 (active). llvm18 rebuilt successfully last night from the latest macports update.
The g95 roadblock is still persistent of course. I made the daft mistake of uninstalling R, so will now have to get the precompiled version from r-projects.org. That also means downloading a whole stack of libraries again. This is all a bit frustrating.
As a final comment, there's absolutely NO WAY that I'm installing 15.0.x Sequoia on this current Mac (2019 19,2 i7 machine).
I am not sure why everyone keeps installing a semi-broken Xcode 16 when the native Xcode 15 would have worked perfectly fine, but the fix for R it trivial: just change Darwin 23 to Darwin 22 in the code chunks I referenced above. So that gcc14 is used. However, that gonna require building R stuff from source.
MacPorts should have informed users to avoid Xcode 16 on Sonoma. And as long as buildbots use one Xcode and end-users use another, incompatible one, there is no general fix for the issue.
comment:11 follow-up: 21 Changed 3 months ago by barracuda156
It is literally just changing 23 to 22.
Default with Sonoma’s native Xcode:
svacchanda@Sergeys-MacBook-Air ~ % port deps R
Full Name: R @4.4.1_3+aqua+builtin_lapack+cairo+gcc13+openmp+tcltk+x11
Build Dependencies: pkgconfig, gcc13, clang-16
Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv,
libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo,
tiff, unzip, xz, zip, zlib, libgcc, libgcc13, cairo,
pango, glib2, freetype, fontconfig, gettext-runtime, tcl,
tk, xorg-libice, xorg-libsm, xorg-libX11, xorg-libXt,
libomp
Runtime Dependencies: clang-16
Edit portfile to force Sequoia-matching behavior:
svacchanda@Sergeys-MacBook-Air ~ % bbedit `port file R`
svacchanda@Sergeys-MacBook-Air ~ % port deps R
Full Name: R @4.4.1_3+aqua+builtin_lapack+cairo+gcc14+openmp+tcltk+x11
Build Dependencies: pkgconfig, gcc14, clang-17
Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv,
libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo,
tiff, unzip, xz, zip, zlib, libgcc, cairo, pango, glib2,
freetype, fontconfig, gettext-runtime, tcl, tk,
xorg-libice, xorg-libsm, xorg-libX11, xorg-libXt, libomp
Runtime Dependencies: clang-17
There won’t be any g95 needed. The problem arose from Apple breaking the Xcode, which made it impossible to compile gcc13 and some Clangs, then MacPorts could do nothing else but blacklist those compilers for the affected Xcode. R port and R PG assume a matching Xcode version, so things broke down, when users began installing Xcode 16, which triggered different blacklists. I.e. in result R and R PG blacklist gcc14 and ask for gcc13, but MacPorts itself blacklists gcc13 and earlier. Since no one remembered to blacklist g95, that gets picked simply because no other option was left.
Change if { ${os.major} > 23 } { to if { ${os.major} > 22 } { three time in R port and three times in R portgroup, that should fix dependencies.
comment:12 follow-up: 13 Changed 3 months ago by kencu (Ken)
if the xcode 16 issue still exists (almost all the hiccups with xcode 16 have been resolved) then you could fork on the xcode version instead of the os version.
comment:13 Changed 3 months ago by barracuda156
Replying to kencu:
if the xcode 16 issue still exists (almost all the hiccups with xcode 16 have been resolved) then you could fork on the xcode version instead of the os version.
If gcc13 builds now with Xcode 16, then gcc13 should be enabled back in MacPorts base (and/or wherever it has been blacklisted earlier). That gonna fix R issue automatically.
comment:14 Changed 3 months ago by ksshannon (Kyle Shannon)
| Cc: | ksshannon added |
|---|
comment:15 Changed 3 months ago by vkuznet (Valentin Kuznetsov)
the same issue, looking forward for the fix.
comment:16 Changed 3 months ago by jowens (John Owens)
| Cc: | jowens added |
|---|
comment:17 Changed 3 months ago by msrski59
| Cc: | msrski59 added |
|---|
comment:18 Changed 3 months ago by szhorvat (Szabolcs Horvát)
| Cc: | szhorvat added |
|---|
comment:19 Changed 2 months ago by msrski59
On a lark I upgraded to Xcode 16.1 to see if the breakage had been fixed. No joy -- same error when trying to build R.
comment:20 Changed 2 months ago by jeremyhu (Jeremy Huddleston Sequoia)
I'm trying to read through this report because someone filed a radar about "Current xcode broke the use of macports and R (see item see https://trac.macports.org/ticket/71068)" last week. Unfortunatley, the amount of detail in that radar is about as lacking as this ticket.
Can someone please explain *HOW* Xcode broke the port or *WHAT* specifically Xcode 16 (or, presumably, the CLTools?) are doing that is impacting this port? I see one comment about "Apple breaking the Xcode, which made it impossible to compile gcc13 and some Clangs" ... is that what the radar is commenting on? Assuming so, can you provide specifics about what exactly broke there?
Is the issue that g95 is somehow getting pulled into the dependency graph when Xcode 16 is installed? Assuming so, that probably has nothing to do with Xcode since Xcode isn't even being used.
Given the build dependencies here include clang-16, I'm curious if MacPorts is picking up Xcode 16's clang (Apple clang version 16) and going down some differnet path in toolchain resolution.
--
FWIW, I see:
$ port deps R
Full Name: R @4.4.2_0+aqua+builtin_lapack+cairo+gcc14+openmp+tcltk+x11
Build Dependencies: pkgconfig, gcc14, clang-18
Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv, libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo, tiff, unzip, xz, zip, zlib, libgcc,
cairo, pango, glib2, freetype, fontconfig, gettext-runtime, tcl, tk, xorg-libice, xorg-libsm, xorg-libX11, xorg-libXt, libomp
Runtime Dependencies: clang-18
comment:21 Changed 2 months ago by Alex11N
Replying to barracuda156:
It is literally just changing 23 to 22.
Default with Sonoma’s native Xcode:
svacchanda@Sergeys-MacBook-Air ~ % port deps R Full Name: R @4.4.1_3+aqua+builtin_lapack+cairo+gcc13+openmp+tcltk+x11 Build Dependencies: pkgconfig, gcc13, clang-16 Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv, libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo, tiff, unzip, xz, zip, zlib, libgcc, libgcc13, cairo, pango, glib2, freetype, fontconfig, gettext-runtime, tcl, tk, xorg-libice, xorg-libsm, xorg-libX11, xorg-libXt, libomp Runtime Dependencies: clang-16Edit portfile to force Sequoia-matching behavior:
svacchanda@Sergeys-MacBook-Air ~ % bbedit `port file R` svacchanda@Sergeys-MacBook-Air ~ % port deps R Full Name: R @4.4.1_3+aqua+builtin_lapack+cairo+gcc14+openmp+tcltk+x11 Build Dependencies: pkgconfig, gcc14, clang-17 Library Dependencies: bzip2, curl, gnutar, gzip, icu, ld64, less, libiconv, libjpeg-turbo, libpng, pcre, pcre2, readline, texinfo, tiff, unzip, xz, zip, zlib, libgcc, cairo, pango, glib2, freetype, fontconfig, gettext-runtime, tcl, tk, xorg-libice, xorg-libsm, xorg-libX11, xorg-libXt, libomp Runtime Dependencies: clang-17There won’t be any g95 needed. The problem arose from Apple breaking the Xcode, which made it impossible to compile gcc13 and some Clangs, then MacPorts could do nothing else but blacklist those compilers for the affected Xcode. R port and R PG assume a matching Xcode version, so things broke down, when users began installing Xcode 16, which triggered different blacklists. I.e. in result R and R PG blacklist gcc14 and ask for gcc13, but MacPorts itself blacklists gcc13 and earlier. Since no one remembered to blacklist g95, that gets picked simply because no other option was left.
Change
if { ${os.major} > 23 } {toif { ${os.major} > 22 } {three time in R port and three times in R portgroup, that should fix dependencies.
Thanks for that - worked a treat. port wanted clang/llvm-17, and once that was done the R packjage with gcc14 support and NO g95 downloaded, and the build went without a hitch. And I've learnt a bit more about how ports work - bargain!b This was on macOS 14.7.1 and CLTs 16.1.
Cheers, Alex.
comment:22 Changed 5 weeks ago by jgrg (James Gilbert)
I just ran into this. Please can the port files be updated with the fix?
comment:23 Changed 3 weeks ago by JDLH (Jim DeLaHunt)
Me too! I just encountered this problem on macOS Sonoma 14.7.2, Darwin kernal 23.6, command-line-tools 16.2:
% uname -v Darwin Kernel Version 23.6.0: Fri Nov 15 15:13:15 PST 2024; root:xnu-10063.141.1.702.7~1/RELEASE_ARM64_T6000 % pkgutil --pkg-info=com.apple.pkg.CLTools_Executables | /usr/bin/grep "version" version: 16.2.0.0.1.1733547573
To echo the other James, Please can the port files be updated with the fix?
Also, Replying to barracuda156:
I am not sure why everyone keeps installing a semi-broken Xcode 16 when the native Xcode 15 would have worked perfectly fine, but the fix for R it trivial: just change Darwin 23 to Darwin 22 in the code chunks I referenced above. So that gcc14 is used. However, that gonna require building R stuff from source.
MacPorts should have informed users to avoid Xcode 16 on Sonoma. And as long as buildbots use one Xcode and end-users use another, incompatible one, there is no general fix for the issue.
The MacPorts Guide, section 2.1. "Install Xcode" says,
Note
Always make sure to install the latest available version of Xcode for your macOS release; using outdated versions of Xcode may cause port install failures. Also note that Xcode … is updated via the Mac App Store starting with 10.7.
The App Store encourages me to keep installing new versions of the apps it installs. Thus, it's not surprising that Sonoma users will have the latest version of XCode installed.
comment:24 Changed 3 weeks ago by JDLH (Jim DeLaHunt)
| Cc: | JDLH added |
|---|
comment:25 Changed 3 weeks ago by JDLH (Jim DeLaHunt)
Inspired by barracuda156, I made private copies of math/R/Portfile and _resources/port1.0/group/R-1.0.tcl, and changed three occurrences of "23" to "22" in each file. I was able to build and install the R port successfully. I am on macOS Sonoma 14.7.2, Darwin kernal 23.6, and command-line-tools 16.2.
Why did I also change the R portgroup source? Because of stern comments like this in the R Portfile:
NOTE : Keep this setting in sync with the one in the R portgroup.
I could submit this change as a pull request. However, the comments also say,
The decision when to migrate to a new compiler is then in the hands of the R maintainers.…
I am not confident that I understand the issues at stake, especially in #67144. I do not understand the R sources well enough.
How do you get a dependency on
g95?Rusesgfortranfrom gcc13, nothing uses g95.% port rdeps R The following ports are dependencies of R @4.4.1_3+aqua+builtin_lapack+cairo+gcc13+openmp+tcltk+x11: pkgconfig libiconv gperf gcc13 xz gettext ncurses gettext-tools-libs libtextstyle gettext-runtime texinfo help2man perl5.34 db48 gdbm readline p5.34-locale-gettext cctools gmp m4 isl ld64 ld64-xcode libmpc mpfr zlib zstd lz4 gcc_select libgcc13 libgcc libgcc14 gcc13-libcxx clang-16 cmake libcxx curl brotli cmake-bootstrap nghttp2 libidn2 libunistring autoconf automake libtool libpsl python310 bzip2 expat libedit libffi dejagnu expect tcl openssl openssl3 sqlite3 python_select-310 python_select python3_select-310 python3_select curl-ca-bundle unzip perl5 libarchive libxml2 icu lzo2 libb2 python311 python_select-311 python3_select-311 py311-pygments py311-build py-bootstrap-modules py311-installer py311-packaging py311-pretend py311-setuptools py311-wheel py311-flit_core py311-pytest py311-setuptools_scm py311-attrs py311-hatchling py311-editables py311-pathspec py311-pluggy py311-trove-classifiers py311-calver hatchling_select py311-hatch-fancy-pypi-readme py311-hatch-vcs py311-hypothesis py311-sortedcontainers py311-zopeinterface py311-zope-event py311-iniconfig py311-py pytest_select py311-pyproject_hooks py311-testpath pygments_select py311-yaml py311-cython-compat libyaml libomp llvm-16 xar llvm_select clang_select gnutar gzip less pcre2 libjpeg-turbo libpng pcre tiff lerc libdeflate zip cairo libpixman meson py312-meson py312-build py312-installer python312 python_select-312 python3_select-312 py312-packaging py312-pretend py312-setuptools py312-wheel py312-flit_core py312-pytest py312-setuptools_scm py312-attrs py312-hatchling py312-editables py312-pathspec py312-pluggy py312-trove-classifiers py312-calver py312-hatch-fancy-pypi-readme py312-hatch-vcs py312-hypothesis py312-sortedcontainers py312-zopeinterface py312-zope-event py312-iniconfig py312-py py312-pyproject_hooks py312-testpath ninja re2c bison bison-runtime glib2 libelf fontconfig freetype ossp-uuid xrender xorg-libX11 xorg-xtrans xorg-xorgproto xorg-util-macros xorg-libXdmcp xorg-libXau xorg-libxcb xorg-xcb-proto xorg-libXext xorg-xcb-util pango gobject-introspection py312-cython cython_select py312-mako py312-markupsafe py312-markdown fribidi harfbuzz graphite2 py311-fonttools py311-cython fonttools_select py311-lxml libxslt py311-brotli py311-zopfli py311-unicodedata2 Xft2 tk xorg-libXScrnSaver xorg-libice xorg-libsm xorg-libXt