Merging rev-upgrade

[Clemens Lang]

On Mon, Dec 12, 2011 at 06:35:06PM -0800, Bradley Giesbrecht wrote:
> Output is minimal so here:
> $ sudo port -d rev-upgrade
> DEBUG: Ignoring loadcommand containing @exectuable_path in /Applications/MacPorts/Pallet.app/Contents/MacOS/Pallet
> DEBUG: Missing architecture arm in file /usr/lib/libSystem.B.dylib
> DEBUG: Missing architecture arm in file outside prefix referenced from /opt/local/lib/apple-gcc42/gcc/i686-apple-darwin10/4.2.1/libstdc++.dylib
> DEBUG: Missing architecture arm in file /usr/lib/libSystem.B.dylib
> DEBUG: Missing architecture arm in file outside prefix referenced from /opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin10/4.2.1/libstdc++.dylib
> --->  Scanning binaries for linking errors
> --->  No broken files found. :)

Did you uninstall percona or something? Unless you fixed the problem
manually, rev-upgrade should keep reporting it, so I wonder why it is
working fine now.

> It did rebuild, 3 times. But percona (mysql fork) is broken. Shouldn't
> rev-upgrade have caught this?

First off: I'm still trying to get percona to build on Lion/Xcode 4.2.1,
so this is what I think the problem might be from looking at your output
and my code:

In the output you posted in the last mail, rev-upgrade followed a
loadcommand somewhere in py26-mysql, which referred to
/opt/local/lib/libmysqlclient.18.dylib, which doesn't exist, because
percona apparently doesn't install it there. Since rev-upgrade can't
guess which port should provide this file it can only mark py26-mysql as
broken and hope a rebuild will trigger installing the correct dependeny
or re-link against an existing libmysqlclient.

Now the rebuild should probably correct such problems, unless the
compiler writes the linked library's LC_ID_DYLIB loadcommand (the one in
the first line of otool output) into the binary. As you can see in the
case of /opt/local/lib/mysql5/mysql/libmysqlclient.18.dylib, your
compiler may have found this lib, linked against it and wrote it's
LC_ID_DYLIB (which happens to be the non-existant
/opt/local/lib/libmysqlclient.18.dylib) into the binary, effectively
producing a broken binary.

> $ otool -L /opt/local/lib/mysql5/mysql/libmysqlclient.18.dylib
> /opt/local/lib/mysql5/mysql/libmysqlclient.18.dylib:
> 	/opt/local/lib/libmysqlclient.18.dylib (compatibility version 18.0.0, current version 18.0.0)
> 	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
> 	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
> 	/opt/local/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
> 	/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)

rev-upgrade scans every binary installed by macports, follows it's
loadcommands and checks existance and compatibility version. It does not
check whether the path of the file and it's LC_ID_DYLIB loadcommand are
the same (and it can't, because you could be sym- or hardlinking files).
One could check, whether the file in LC_ID_DYLIB actually exists,
though.

In your case, i'd say the percona port is buggy and should be fixed.

-- 
Clemens Lang
GSoC Student