libcxx/libcxxabi: OS update can render system unusable

[neverpanic (Clemens Lang)]

Because the libcxx and libcxxabi ports install a library directly in /usr/lib, an OS update can cause the deletion of /usr/lib/libc++.1.dylib; if this happens when upgrading to 10.9, the system might be completely unusable. This happens by:

• installing libcxx and libcxxabi on Snow Leopard
• upgrading the OS to Lion or newer
• upgrading MacPorts
• starting to upgrade all outdated ports

This very last operation will deactivate the libcxx and libcxxabi ports at some point, removing the files they used to install on Snow Leopard, which will include /usr/lib/libc++.dylib and /usr/lib/libc++abi.dylib, even though these files are no longer the MacPorts-installed files but have been taken over by the OS instead. The same will apply to all files installed by these two ports in /usr, but the libraries are by far the most critical.

Please find a different way to solve this issue if you want to provide a libc++ in /usr/lib, e.g. by installing the libraries below $prefix and creating symlinks in post-activate. Then, carefully write a post-deactivate hook that will remove just those very symlinks to $prefix when deactivating, so the OS' files are left in-place when uninstalling on a different version OS X than the port was installed on.

[cooljeanius (Eric Gallager)]

Cc Me!

[jeremyhu (Jeremy Huddleston Sequoia)]

So base just removes any file without actually matching that it was the one installed by it? That seems like a bug in base to me, but we'll have to work around it in the port... sigh...

[danielluke (Daniel J. Luke)]

Replying to jeremyhu@…:

So base just removes any file without actually matching that it was the one installed by it?

Yes, that's also part of the reason why configuration files need to be handled specially by ports (so that upgrade doesn't uninstall a user-modified configuration).

[larryv (Lawrence Velázquez)]

Cc Me!

[landonf (Landon Fuller)]

Do these libraries need to be installed in /usr/lib at all? It doesn't seem safe/appropriate/etc to be installing any files in a canonically operating-system owned location like /usr/lib, with or without workarounds.

Maybe base should treat (/usr, /etc, /var, ...) violations as hard errors that can't be overridden with destroot.violate_mtree ? MacPorts could move (rather than delete) modified files like some other systems do, but that wouldn't fix the this particular issue.

[jeremyhu (Jeremy Huddleston Sequoia)]

Yes, the files need to be in /usr/lib.

This upgrade, uninstall, removing the new host version case was not something I considered. This has also been this way for quite some time with nobody tripping over it, but that's not excuse.

[jeremyhu (Jeremy Huddleston Sequoia)]

r117283