[MacPorts] #65510: Can no longer compile R packages with MacPorts's GCC (@rpath related)
MacPorts
noreply at macports.org
Tue Aug 15 02:12:56 UTC 2023
#65510: Can no longer compile R packages with MacPorts's GCC (@rpath related)
---------------------------+--------------------
Reporter: szhorvat | Owner: (none)
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: fixed | Keywords:
Port: gcc11, gcc12 |
---------------------------+--------------------
Comment (by kencu):
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.
--
Ticket URL: <https://trac.macports.org/ticket/65510#comment:10>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list