Detect opportunistic linking and unnecessary dependencies

Ryan Schmidt ryandesign at
Tue Feb 26 20:57:44 PST 2013

On Feb 16, 2013, at 04:16, Rainer Müller wrote:
> On 2013-02-16 05:51, Ryan Schmidt wrote:
>> It would be great if MacPorts would automatically detect dependency problems when installing ports.
>> For example, if a port links with a library but does not declare a dependency on it, I'd love to see a warning:
>> Warning: /opt/local/bin/foo links with /opt/local/lib/libbar.dylib but port foo does not declare a library dependency on port bar
>> Conversely, how about a warning when a library dependency is declared but that port is not actually linked with:
>> Warning: none of the files installed by port foo link with any of the libraries installed by library dependency bar
>> This is more problematic to implement because some ports open libraries via dlopen (i.e. wine), and things like python modules don't link with the other modules they depend on either. But on the other hand it's also important to have this check, because I really want to be able to easily find all the ports to which we've added unnecessary library dependencies over the years due to the glibtool overlinking problem that we've now corrected in base.
> This is exactly what the GSoC project in 2011 for post-destroot checks
> by Felipe Tanus (fotanus@) under supervision by Perry Lee (perry@) was
> about. More can be found in the original proposal and a mail from Felipe
> [1,2]. The code is in our repository in a branch in the path
> branches/gsoc11-post-destroot [3].

Cool. Did/does it work? Any reason it wasn't merged into trunk, other than lack of time and testing?

> There is also a set of tests in an additional ports tree [4], that is
> supposed to test mtree violations, mislinking and wrong/missing
> architectures.
> Back in October, I did a merge from trunk into that branch. Remaining
> work that needs to be done for this would be another rebase onto the
> current base from trunk and at best, integrate the test ports into our
> test suite in the base code.
> Furthermore, the use of pextlib1.0/macho.c should be replaced by using
> machista1.0 to avoid code duplication. Also the name "whitelist.conf"
> which contains libaries that are allowed to be linked without declaring
> a dependency should be renamed to something more descriptive. The list
> of system libraries needs ton be updated for Mountain Lion as well (due
> to the introduction of /usr/lib/system/).

More information about the macports-dev mailing list