Preventing check of sharedlibs in rev-upgrade

Joshua Root jmr at macports.org
Wed Jun 20 16:50:37 UTC 2018


The basic test is that the files referred to by each mach-o file's load
commands exist. It uses pretty much the same information that is shown
by 'otool -L /path/to/file'.

If you run rev-upgrade with the -v (or -d) option, it will show the
specifics of why it considers files to be broken.

- Josh

On 2018-6-21 02:01 , Artur Szostak wrote:
> Is the algorithm for the rev-upgrade stage documented anywhere so I can understand exactly how it is trying to identify that a shared library is broken?
> 
> ________________________________________
> From: Joshua Root <jmr at macports.org>
> Sent: 20 June 2018 13:34
> To: Artur Szostak
> Cc: MacPorts Users
> Subject: Re: Preventing check of sharedlibs in rev-upgrade
> 
> Artur Szostak wrote:
>> Is there any way of telling MacPorts to not consider one, more or all shared libraries when attempting its check for broken libraries in a Portfile? I have some Java software which is precompiled and also delivering some additional shared libraries. Unfortunately, MacPorts is incorrectly detecting some of the shared libraries as broken and attempting to recompile the package.
> 
> You can't disable it on a per-port basis, but you can prevent
> rev-upgrade from running automatically, or put it in report-only mode,
> with settings in macports.conf.
> 
> If it is indeed incorrectly considering some files broken, that is a bug
> that we should fix, so please file a ticket. (Have you checked that the
> detected brokenness could not be fixed with install_name_tool like e.g.
> oracle-instantclient does?)
> 
> - Josh
> 



More information about the macports-users mailing list