MacOSX10.7.sdk and MacOSX10.9.sdk: Marked as broken by rev-upgrade

[rmottola (Riccardo)]

--->  Found 1045 broken files, matching files to ports   
Error: Port MacOSX10.7.sdk is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Error: rev-upgrade failed: Port MacOSX10.7.sdk still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

the same happens also when installing 10.9 sdk on 10.13 High Sierra.

I attach the debug log, I guess the issue is i386 architecture.

Error: Port MacOSX10.9.sdk is still broken after rebuilding it more than 3 times.
Error: Please run port -d -y rev-upgrade and use the output to report a bug.
Error: rev-upgrade failed: Port MacOSX10.9.sdk still broken after rebuilding 3 times
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[rmottola (Riccardo)]

10.9 revupgrade

[ryandesign (Ryan Carsten Schmidt)]

So they don't fail to install; they're just marked as broken by rev-upgrade.

I assume that if you use these SDK ports (i.e. specifying their paths with -isysroot and -syslibroot when building something) then the brokenness reported by rev-upgrade will not exist.

Taking as an example the first problem in your log:

Could not open /System/Library/PrivateFrameworks/ContactsData.framework/Versions/A/ContactsData: Error opening or reading file (referenced from /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook)
DEBUG: Marking /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook as broken

Yes, ContactsData.framework does not exist in /System/Library/PrivateFrameworks on High Sierra but it did exist there on Mavericks and should exist in /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/PrivateFrameworks.

My inclination would be to ignore the rev-upgrade message or disable the use of rev-upgrade. (I have it disabled on my system which is why I didn't notice this issue.) Maybe there should be a way for a port to tell rev-upgrade not to scan it.

[rmottola (Riccardo)]

SO you say that rev-upgrade is reporting a false positive, that everything is "fine" even if it looks broken. If installation can indeed mark a package as not to be scanned, then fine.

[ryandesign (Ryan Carsten Schmidt)]

Replying to rmottola:

SO you say that rev-upgrade is reporting a false positive, that everything is "fine" even if it looks broken.

As far as rev-upgrade knows, it is broken. rev-upgrade does not understand how SDKs work.

If installation can indeed mark a package as not to be scanned, then fine.

There is no feature in MacPorts to do that today.

[RJVB (René Bertin)]

Replying to ryandesign:

Taking as an example the first problem in your log:

Could not open /System/Library/PrivateFrameworks/ContactsData.framework/Versions/A/ContactsData: Error opening or reading file (referenced from /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook)
DEBUG: Marking /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook as broken

Yes, ContactsData.framework does not exist in /System/Library/PrivateFrameworks on High Sierra but it did exist there on Mavericks and should exist in /opt/local/Developer/SDKs/MacOSX10.9.sdk/System/Library/PrivateFrameworks.

Wasn't there another use case where rev-upgrade balks on a missing shared library, ignoring the fact that it's linked weakly and thus doesn't (necessarily) throw an error when the dependent binary is loaded?

Treating the symptom side of things: make rev-upgrade only warn about missing dependents that are not installed through MacPorts (or only those that belong to the system).

Another workaround: teach rev-upgrade about the MacOSX.sdk ports. I assume that their intention was never to be used as runtime for the binaries that you build against them? If so, rev-upgrade should/could scan only for missing files but should not do any tests concerning "runnability".

If however my assumption is incorrect then rev-upgrade does flag an actual error and it *may* be possible to fix them with install_name_tool -change as long as that doesn't change the ids recorded in binaries built against these SDKs.