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
