R build fails

[ShadSterling (Shad Sterling)]

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

[barracuda156]

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).

[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.

[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?

[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"

[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?

[barracuda156]

Replying to ShadSterling:

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.

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

[ShadSterling (Shad Sterling)]

Why is a build with the gcc12 variant referring to a library provided by libgcc13 rather than libgcc12?

[barracuda156]

Replying to ShadSterling:

Why is a build with the gcc12 variant referring to a library provided by libgcc13 rather than libgcc12?

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.

16. S. libgfortran that is sitting in /opt/local/bin/gcc12 is in fact just a symlink to libgfortran in libgcc directory.

[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

[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 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

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.)