port rev-upgrade stumbles over -weak_framework library dependencies

[RJVB (René Bertin)]

While trying to get QtWebEngine (QWE) 5.7.0 to build on OS X 10.9 I ran into an issue with port rev-upgrade:

the QtWebEngineCore.framework links to the Bluetooth framework, called IOBluetooth on OS X 10.9, which contains the CoreBluetooth framework. QWE 5.7 now requires to 10.10 SDK to build, and that SDK provides the CoreBluetooth framework directly in /System/Library/Frameworks.

As a result, the QtWebEngineCore framework has a dependency on /System/Library/Frameworks/CoreBluetooth/.../CoreBluetooth, which evidently doesn't exist on 10.9 . The build system handles that by linking the framework with -weak_framework, and the resulting QtWebEngineCore framework loads just fine.

However, port rev-upgrade apparently only sees the dependency and not its weak nature, so an error is raised that shouldn't occur.

[larryv (Lawrence Velázquez)]

And what error is that?

[RJVB (René Bertin)]

The usual error about a missing library, in this case /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth

[jasonliu-- (Jason Liu)]

I was recently also hit with this problem in a port that I am trying to make a Portfile for, where the upstream devs are providing some portions of their library as pre-compiled binary blobs, which have weakly linked dependencies. It looks like one workaround is to use install_name_tool and setting the weak dependency to something that is guaranteed to exist, such as the root folder (/).

See: ​https://stackoverflow.com/questions/4824885/remove-dependent-shared-library-from-a-dylib

[chrstphrchvz (Christopher Chavez)]

I have proposed a fix for this: ​https://github.com/macports/macports-base/pull/301

[jasonliu-- (Jason Liu)]

I can also corroborate that the workaround does appear to work; although instead of changing the offending weak link to be the root folder, I made it to be ${prefix} .

[fhgwright (Fred Wright)]

I've run into a somewhat related problem with rev-upgrade and the MacOSX*.sdk ports. I wasn't surprised to see errors with a given SDK on an older OS; I was somewhat surprised to see errors with a given SDK on a newer OS; and I was really surprised to see errors in some cases with a given SDK on a matching OS (10.7 and 10.10).

Since the SDK ports are just verbatim copies of Apple's code with no port dependencies, it's clearly completely useless to apply the rev-upgrade processing to them at all. At best this is just a waste of time, and at worst it creates false errors and perhaps useless "rebuilds". For cases like that, what's needed is a port attribute to opt out of rev-upgrade altogether (essentially by pretending that they have no binaries).

The weak-linking case is a little more complicated, since ports that fail to make the appropriate runtime checks for weak linking are genuinely broken by weak-linking failures, while ports that do make the appropriate checks should be able to take such failures in stride. I don't think there's any automated way to tell the difference, so it would need to be another port attribute - one that specifies ignoring weak-linking failures without opting out of rev-upgrade altogether.

[chrstphrchvz (Christopher Chavez)]

In 77e333a2a7915d7f383fd8781fa52b4c432191b8/macports-base (master):

rev-upgrade: skip weakly-linked

Fixes: #52700