Opened 23 months ago

Closed 23 months ago

Last modified 10 months ago

#65510 closed defect (fixed)

Can no longer compile R packages with MacPorts's GCC (@rpath related)

Reported by: szhorvat (Szabolcs Horvát) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: cjones051073 (Chris Jones)
Port: gcc11, gcc12

Description

Since recently, I can no longer use MacPort's GCC/gfortran to compile R packages. The packages will not load. The error is:

Library not loaded: @rpath/libgfortran.5.dylib
...
Reason: image not found

If I look at what the shared library that was compiled references with otool -L, I see this:

...
/opt/local/lib/libgmp.10.dylib (compatibility version 15.0.0, current version 15.1.0)
/opt/local/lib/libglpk.40.dylib (compatibility version 44.0.0, current version 44.1.0)
...
@rpath/libgfortran.5.dylib (compatibility version 6.0.0, current version 6.0.0)
@rpath/libquadmath.0.dylib (compatibility version 1.0.0, current version 1.0.0)

As I recall, in the past, libgfortran and libquadmath used to be referenced with full path. Now they are referenced with @rpath. I do not know how shared libraries are looked up on macOS, or what @rpath means, but I assume this is the source of the problem.

This makes it impossible to use MacPort's GCC to compile R packages, which is a serious problem for me.

Is there a workaround?

Change History (10)

comment:1 Changed 23 months ago by cjones051073 (Chris Jones)

exactly which versions of libgcc12 and gcc12 are you using ?

comment:2 Changed 23 months ago by cjones051073 (Chris Jones)

Please also past the complete log for a failed attempt to build R

comment:3 Changed 23 months ago by cjones051073 (Chris Jones)

Just for info, the @rpath is an intentional transition upstream gcc has made, so we have to learn to live with it. See

https://trac.macports.org/ticket/65472

comment:4 Changed 23 months ago by szhorvat (Szabolcs Horvát)

In the meantime, it was communicated to me that from now on I need to use the following option when linking:

-Wl,-rpath /opt/local/lib/gcc12

This does work.

comment:5 Changed 23 months ago by cjones051073 (Chris Jones)

Please do not use the above, but instead use

-Wl,-rpath /opt/local/lib/libgcc

comment:6 Changed 23 months ago by szhorvat (Szabolcs Horvát)

I am using gcc12 @12.1.0_5 and libgcc12 @12.1.0_5. To be clear, I was not building R, but building the igraph R package, which uses gfortran. I was using the CRAN distribution of R, not MacPort's, but I set it up to use MacPorts's compiler. I do this by adding the following to ~/.R/Makevars:

CCACHE=/opt/local/bin/ccache
CC = $(CCACHE) /opt/local/bin/clang-mp-14
CXX = $(CCACHE) /opt/local/bin/clang++-mp-14
FC = $(CCACHE) /opt/local/bin/gfortran-mp-12
F77 = $(CCACHE) /opt/local/bin/gfortran-mp-12
FLIBS = -L/opt/local/lib/gcc12 -lgfortran -lquadmath -lm -Wl,-rpath /opt/local/lib/libgcc
CPPFLAGS=-I/opt/local/include
LDFLAGS=-L/opt/local/lib

Officially, using any other compiler than what R itself was compiled with is not supported for building R packages. However, this used to work until a few days ago.

Thanks for the help Chris, I can compile R packages again now, so feel free to close the issue.

Last edited 23 months ago by szhorvat (Szabolcs Horvát) (previous) (diff)

comment:7 Changed 23 months ago by cjones051073 (Chris Jones)

in the above you should also replace

-L/opt/local/lib/gcc12

with

-L/opt/local/lib/libgcc

comment:8 Changed 23 months ago by cjones051073 (Chris Jones)

Resolution: fixed
Status: newclosed

comment:9 Changed 10 months ago by barracuda156

What was the cause of the issue though?

I think I did not see anything of this sort happening, though my gcc12 perhaps borrows a few Iain’s fixes.

UPD. Sorry, I am brain-dead apparently now: it was 13 months ago, we had no R packages then.

Last edited 10 months ago by barracuda156 (previous) (diff)

comment:10 Changed 10 months ago by kencu (Ken)

Iain has enabled rpaths to find the gcc libraries on newer systems by default. On older systems, full paths are still used (somewhere around 10.11 was the cutoff).

Iain had originally set up the rpath handling on Darwin systems such that software (executables and dylibs) would look only in the specific directory where the building version of gcc's libraries were stored.

I asked him for a new option, so that we could add an rpath of our own to all gcc-built software to where MacPorts likes to keep these libraries (/opt/local/lib/libgcc). He provided it:

--with-darwin-extra-rpath=${mp_extra_rpath}

This works quite well for anything built with a newer gcc that supports this rpath addition.

For older gccs (not an issue on newer systems anyway as older gccs don't often build on newer systems), and for anything built with clang, you have to add the extra rpath search path manually, as otherwise the executable or dylib will not know where to find the gcc library.

That is what this extra flag does, used during the link to add the rpath search path:

-Wl,-rpath /opt/local/lib/libgcc

It manually adds the search path that a newer gcc would automatically add during the link phase.

Note: See TracTickets for help on using tickets.