"port upgrade" error message usability

Julien Salort listes at salort.eu
Mon Jan 31 19:18:38 UTC 2022


Le 31/01/2022 à 12:08, Ryan Schmidt a écrit :

> 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.

Thanks for this clear explanation.

I have tried adding -rpath ${prefix}/lib/${gccdir} in Octave Portfile, 
but then I get into this problem:

:info:build libtool: warning: ignoring multiple '-rpath's for a libtool 
library

[...]

:info:build clang: error: no such file or directory: 
'/opt/local/lib/gcc-devel/liboctave.8.dylib'

Indeed, there was already a -rpath /opt/local/lib/octave/6.4.0, and 
adding -rpath with gcc apparently then prevents from finding liboctave...

I have no idea how to fix this.

Julien



More information about the macports-dev mailing list