On Jan 30, 2022, at 23:16, Andrew Janke wrote:
> On 1/30/22 10:16 AM, Julien Salort wrote:
>> Le 30/01/2022 à 10:30, Andrew Janke a écrit :
>>
>>> I'm the primary maintainer for Octave.app (https://octave-app.org/), a
>>> "native Mac app" distribution of GNU Octave
>>> (https://www.gnu.org/software/octave/index), and I'm getting more in to
>>> MacPorts recently because Octave.app is currently built on Homebrew and I'm
>>> considering migrating it to MacPorts, because I want to continue supporting
>>> macOS 10.14 with it. (10.15+ breaks some apps, so I want to be able to
>>> support the diehards (like me) who are sticking with 10.14).)
>>
>> That's very interesting. Maybe you will be able to help fix the Octave port.
>>
>> I haven't been able to install it on Monterey. It seems to be a linking
>> problem, but the Octave Portfile is too complex for me to try and fix it.
>> There are open tickets for this issue, which have been opened for nearly a
>> year:
>>
>> https://trac.macports.org/ticket/62874
>>
>> also for arm64:
>>
>> https://trac.macports.org/ticket/61860
>>
>> The log says:
>>
>> :info:destroot dyld[24113]: Library not loaded: @rpath/libgfortran.5.dylib
> [...]
>>
>> Someone proposed a workaround by manually changing to the actual path, and
>> it seems to work. If someone could explain clearly what this @rpath thing
>> actually is, and if there is a way to fix it globally, I would be interested
>> to know.
>>
>> Julien
>>
> There's a fair chance I can. I've sorted out @rpath stuff on Octave builds
> before, though it's been a while. @rpath is an extra-dynamic location
> mechanism for referencing/locating shared libraries; it stands for "relative
> path" and means to look for the referenced DLL file based on a search path
> that includes locations relative to the current filesystem location of the
> referencing file, evaluated dynamically at library load & link time. But I
> forget the details.
>
> Later this week I'll have a look around for the reference documentation that
> says exactly how it works, and what compiler options control whether and how
> @rpath is used in built binaries. I'm not sure if the proper fix here is to
> replace @rpath with a different referencing style, or do something to alter
> @rpath's search path so it includes the right MacPorts-controlled /opt/local
> subdirs for DLLs.
The situation is:
libgfortran.5.dylib was built with an install_name containing @rpath. (It was
the choice of the developers of libgfortran (the developers of gcc), or
possibly whoever updates the gcc-devel portfile, to make it do that.)
This means that any consumer of that library needs to specify what path(s)
@rpath should expand to at runtime, by using the `-rpath` flag at link time.
For example if libgfortran.5.dylib is in fact located at
/opt/local/lib/libgcc/libgfortran.5.dylib in the filesystem, then when you link
against it with `-lgfortran` you should also specify `-rpath
/opt/local/lib/libgcc`.
This all seems complicated and unnecessary to me, besides which @rpath didn't
exist until Mac OS X 10.5 and somehow we got along just fine without it until
then, therefore we usually do not choose to have libraries install themselves
with @rpath-based install_names (they should use simple absolute path
install_names instead) but I understand that the developers of gcc recently
decided to use @rpath here, though I do not understand why or whether we can
somehow still tell it not to do that.
