#52700 closed defect (fixed)
port rev-upgrade stumbles over -weak_framework library dependencies
Reported by: | RJVB (René Bertin) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | MacPorts 2.9.0 |
Component: | base | Version: | |
Keywords: | Cc: | neverpanic (Clemens Lang), mkae (Marko Käning), chrstphrchvz (Christopher Chavez), jasonliu-- (Jason Liu), fhgwright (Fred Wright) | |
Port: |
Description
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.
Change History (12)
comment:1 Changed 8 years ago by larryv (Lawrence Velázquez)
Cc: | neverpanic added |
---|
comment:2 Changed 8 years ago by RJVB (René Bertin)
The usual error about a missing library, in this case /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
comment:3 Changed 8 years ago by mkae (Marko Käning)
Cc: | mkae added |
---|
comment:4 Changed 13 months ago by 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
comment:5 Changed 13 months ago by chrstphrchvz (Christopher Chavez)
I have proposed a fix for this: https://github.com/macports/macports-base/pull/301
comment:6 Changed 13 months ago by chrstphrchvz (Christopher Chavez)
Cc: | chrstphrchvz added |
---|
comment:7 Changed 13 months ago by 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}
.
comment:8 Changed 13 months ago by jasonliu-- (Jason Liu)
Cc: | jasonliu-- added |
---|
comment:9 Changed 13 months ago by 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.
comment:10 Changed 13 months ago by fhgwright (Fred Wright)
Cc: | fhgwright added |
---|
comment:11 Changed 13 months ago by chrstphrchvz (Christopher Chavez)
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:12 Changed 12 months ago by jmroot (Joshua Root)
Milestone: | → MacPorts 2.9.0 |
---|
And what error is that?