"port upgrade" error message usability

[Ryan Schmidt]

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.