[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