Opened 8 months ago
Last modified 8 months ago
#69586 new defect
R build fails
Reported by: | ShadSterling (Shad Sterling) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.9.1 |
Keywords: | Cc: | kjellpk (Kjell Konis), i0ntempest, barracuda156 | |
Port: | R |
Description
Tried to disable everything to get a minimal failing case: port clean R; port install R -accelerate-aqua-atlas-builtin_lapack-cairo-debug-g95-gcc10-gcc11+gcc12-gcc13-gccdevel-java-latex-openblas-openmp-quartz-tcltk-tests-universal-x11
---> Cleaning R ---> Computing dependencies for R ---> Fetching archive for R ---> Attempting to fetch R-4.3.3_2+gcc12.darwin_22.x86_64.tbz2 from https://packages.macports.org/R ---> Attempting to fetch R-4.3.3_2+gcc12.darwin_22.x86_64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/R ---> Attempting to fetch R-4.3.3_2+gcc12.darwin_22.x86_64.tbz2 from http://mirror.fcix.net/macports/packages/R ---> Fetching distfiles for R ---> Verifying checksums for R ---> Extracting R ---> Configuring R Warning: Configuration logfiles contain indications of -Wimplicit-function-declaration; check that features were not accidentally disabled: _NL_LOCALE_NAME: found in R-4.3.3/config.log strchr: found in R-4.3.3/config.log ---> Building R Error: Failed to build R: command execution failed Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/main.log for details. Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug. Error: Processing of port R failed
Looks like it has something to do with lapack and/or fortran
:info:build make[4]: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/work/R-4.3.3/src/library/grDevices' :info:build byte-compiling package 'grDevices' :info:build Warning in solve.default(rgb) : :info:build unable to load shared object '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/work/R-4.3.3/modules//lapack.so': :info:build dlopen(/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_R/R/work/R-4.3.3/modules//lapack.so, 0x0006): symbol not found in flat namespace '__gfortran_concat_string' :info:build Error in solve.default(rgb) : LAPACK routines cannot be loaded :info:build Error: unable to load R code in package 'grDevices' :info:build Execution halted
Enabling the other lapack variants accelerate
, builtin_lapack
, openblas
generate what looks like the same error; enabling atlas
says Error: atlas is known to fail
.
Enabling the other fortran variants g95
, gcc10
, and gcc11
also say known to fail
; gcc13
fails to configure; libgcc-devel
says Error: Can't install libgcc-devel because conflicting ports are active: libgcc libgcc12
I just want to keep all my ports up-to-date, I don't need R with a specific lapack or fortran
Attachments (1)
Change History (11)
Changed 8 months ago by ShadSterling (Shad Sterling)
comment:1 Changed 8 months ago by barracuda156
comment:2 Changed 8 months ago by barracuda156
In your quote it seems you tried to build R without any lapack? That cannot work, I guess. But we should make it required in the portfile indeed.
comment:3 Changed 8 months ago by ShadSterling (Shad Sterling)
Of course, I just wanted to narrow down what variants might be involved in the failure, and it doesn't seem to be limited to any particular variant; every choice for fortran fails, and every choice for lapack fails, so I can't work around this failure by choosing a different variant for those or by disabling any other variant. If the log doesn't show why it fails, where else would that show up?
comment:4 Changed 8 months ago by barracuda156
I think this is the problem:
:info:build ld: warning: ignoring file '/opt/local/lib/libgcc/libgfortran.5.dylib': found architecture 'arm64', required architecture 'x86_64' :info:build ld: warning: ignoring file '/opt/local/lib/libgcc/libquadmath.0.dylib': found architecture 'arm64', required architecture 'x86_64'
Why is gcc built for arm64?
If you did not change macports.conf
manually and did not pass build_arch
on command line explicitly, this may be a bug in gcc port or something related. It is not related to R
.
You could do something like (assuming you want to have a build for x86_64 from source):
sudo port -v -n -s upgrade --force libgcc13 build_arch="x86_64"
comment:5 follow-up: 6 Changed 8 months ago by ShadSterling (Shad Sterling)
That didn't change the libgcc13
that was installed, but since R +gcc13
fails to configure I was going to stick with the default gcc12
which makes it to the grDevices
failure.
Nothing is built for arm64, but things that build hassle-free with +universal
are universal. (When I migrate to an apple silicon mac it would be nice to have some things work immediately.) Does R have a new requirement that its fortran variant compiler be installed non-universal?
comment:6 Changed 8 months ago by barracuda156
Replying to ShadSterling:
That didn't change the
libgcc13
that was installed, but sinceR +gcc13
fails to configure I was going to stick with the defaultgcc12
which makes it to thegrDevices
failure.
I did not imply switching to gcc13
(that is possible, but requires tweaks), but:
macmini:~ svacchanda$ port provides /opt/local/lib/libgcc/libgfortran.5.dylib /opt/local/lib/libgcc/libgfortran.5.dylib is provided by: libgcc13
Nothing is built for arm64, but things that build hassle-free with
+universal
are universal. (When I migrate to an apple silicon mac it would be nice to have some things work immediately.) Does R have a new requirement that its fortran variant compiler be installed non-universal?
I do not think there is such a requirement, however it seems that gcc*
in Macports are not built as universal, see #67652
comment:7 follow-up: 8 Changed 8 months ago by ShadSterling (Shad Sterling)
Why is a build with the gcc12
variant referring to a library provided by libgcc13
rather than libgcc12
?
comment:8 Changed 8 months ago by barracuda156
Replying to ShadSterling:
Why is a build with the
gcc12
variant referring to a library provided bylibgcc13
rather thanlibgcc12
?
Both gcc12 and gcc13 use libgcc port, which in turn uses libgcc13. So libgfortran is from libgcc13 for both. gfortran compiler is chosen by the variant, however.
comment:9 follow-up: 10 Changed 8 months ago by ShadSterling (Shad Sterling)
I don't understand what was wrong here, I would expect libgcc*+universal
to provide universal libraries that would have had the required x86_64
and ld
to be able to ignore any other architectures present. But since it seems like something in *gcc*
was broken, I uninstalled *gcc*
and let the dependency resolution reinstall as needed, and now I have R
back. Without knowing what went wrong I'm not sure whether I should expect it to break again at the next update
comment:10 Changed 8 months ago by barracuda156
Replying to ShadSterling:
I don't understand what was wrong here, I would expect
libgcc*+universal
to provide universal libraries that would have had the requiredx86_64
andld
to be able to ignore any other architectures present. But since it seems like something in*gcc*
was broken, I uninstalled*gcc*
and let the dependency resolution reinstall as needed, and now I haveR
back. Without knowing what went wrong I'm not sure whether I should expect it to break again at the next update
Honestly I do not know, since I do not have a system combining x86_64 with arm64.
On a general note, things do not work amazingly well with universal builds (unfortunately), and cross-family ones are likely to be more problematic. Since not many people test those, and issues tend to be non-trivial to deal with, fixing may not happen fast.
(Maybe you could consider having Macports in default prefix building for one, native arch (since then you can have a benefit of pre-built ports), and have a separate tree for universal builds (which anyway have to be build from source normally). And then keep all stuff which is universal-unfriendly in the main one.)
Just to be clear, did you try a default install, without specifying variants manually? I think nobody has ever tested every combination, so that is likely not to work.
atlas
does not build for newer systems, I think, because it uses gcc6 (unless something changed there). Fortran 95 is also super-old.On every update
R
should pass CI on GitHub, so at least on macOS 11+ default variants should build. (Though it is possible that something broke down with dependencies).