How to fix "broken ports"?

Clemens Lang cal at macports.org
Mon May 21 04:33:02 PDT 2012


On Mon, May 21, 2012 at 08:01:50AM +0200, Marko Käning wrote:
> 1) OK, I would like to know how rev-upgrade determines that certain
> files are "broken" which is why some ports need a rebuild.

It usually tells you for each file it marks as broken why it thinks it
is broken. In a nutshell, it
    1. loops through all binaries,
    2. loops through all architectures in a given binary
    3. tries to find all libraries linked from that binary in the given
       architecture. Here:
       - paths containing @rpath are ignored; those could be handled,
         but they're few in macports anyway and those binaries using
         @rpath are likely to care about linking on OS X and usually do
         not fail
       - paths containing @executable_path are ignored; we're not the
         linker, we cannot know because of which binary in what location
         a given library is loaded.
       - occurances of @loader_path are heuristically replaced with the
         path of the file itself.
    4. repeat

So, problems might occur at (3), because
  - a referenced library isn't available in a needed architecture
  - a referenced library cannot be found, because there's no file at the
    location in the load command. This happens for all load commands
    using relative paths and probably also for all load commands that
    rely on DLYD_LIBRARY_PATH to be set (e.g. using some script shipped
    with the port). Again, rev-upgrade isn't the linked and cannot know
    whether DYLD_LIBRARY_PATH is set at load time and to what value it
    is set.

> 2) Secondly I'd like to learn how to avoid these broken files. You
> wrote that some ports do not use install_name_tool, but the question
> is how to fix this.

The last point in the list of problems can be fixed by using
install_name_tool, e.g. to replace relative paths with absolute paths.

> 4) The ports which belong to me I have to learn to fix myself and I
> hope you can give me some directions.

Will try to.

> Here is my starting situation after having upgraded all my ports on my
> test installation (I have switched off the automatic rev-upgrade
> procedure, since I know that it is a circular thing):
>      kde4-runtime @4.8.3 
>          /opt/macports-test/Applications/KDE4/khelpcenter.app/Contents/MacOS/khelpcenter
>          /opt/macports-test/Applications/KDE4/knotify4.app/Contents/MacOS/knotify4
>          /opt/macports-test/lib/kde4/libkmanpart.so
>          /opt/macports-test/lib/libkdeinit4_khelpcenter.dylib

Can you re-run with -d? While this output tells you which files are
broken, it unfortunately does not tell you why. Running with -d should
print that information.

-- 
Clemens Lang



More information about the macports-dev mailing list