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