Opened 8 years ago

Closed 12 months ago

Last modified 11 months ago

#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

And what error is that?

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)

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 12 months ago by chrstphrchvz (Christopher Chavez)

Resolution: fixed
Status: newclosed

In 77e333a2a7915d7f383fd8781fa52b4c432191b8/macports-base (master):

rev-upgrade: skip weakly-linked

Fixes: #52700

comment:12 Changed 11 months ago by jmroot (Joshua Root)

Milestone: MacPorts 2.9.0
Note: See TracTickets for help on using tickets.