"port upgrade" error message usability

[Andrew Janke]

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