"port upgrade" error message usability

Ryan Schmidt ryandesign at macports.org
Tue Feb 1 00:29:59 UTC 2022


On Jan 31, 2022, at 13:18, Julien Salort wrote:

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

-rpath flags, in the way I described, are processed by the linker, and the linker has no problem with multiple -rpath flags.

libtool also uses -rpath flags for its own purposes and expects there to be only one.

You can encode the -rpath flags that we want to send to the linker with the -Wl notation so that libtool will ignore them.

So instead of

-rpath ${prefix}/lib/${gccdir}

use

-Wl,-rpath,${prefix}/lib/${gccdir}



More information about the macports-dev mailing list