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.
Cheers,
Andrew
