rev-upgrade and checking for +universal dependencies (and build dependencies)

René J.V. Bertin rjvbertin at gmail.com
Thu Jun 4 05:20:38 PDT 2015


On Thursday June 04 2015 13:15:43 Clemens Lang wrote:

> However your inquiry was to make it find out which binary links against a certain
> architecture of a library, something rev-upgrade does not do.

Then my inquiry was inadequately formulated and/or understood ...
Or rather, `port -v rev-upgrade` indicates which files are responsible for issues found with what ports. I think that's all I'd need.

> If rev-upgrade didn't detect any problems after you did this, the universal
> variant was (a) not required, or (b) required because it's being dlopen(3)'d by
> a 32-bit process, which we cannot statically detect.

Or "required" because of a build dependency of a port that I installed +universal, no?

> > BTW: is +universal "exported" to depends_fetch and/or depends_extract
> > dependencies too?
> 
> No.

That's good to know for future reference :)

> (Or 'installed and depends:python27' to find build deps too.

That turned up at-spi2-atk compared to `installed and dependentof:python27` , and there's a runtime dependency from xorg-libxcb (whatever that library uses python for?!).


> Seems weird that anything
> would require a universal python at build time but not runtime though.)

Yes, it does seem so, and I'm willing to bet that most build-time dependencies (at least on python, or perl, or similar script languages) do not actually have this requirement. But I think we cannot exclude it either, not unless we can assume (or impose) that a +universal build process can never include steps that are to be executed in the target bit-width.
I remember asking why depends_build passes on the +universal variant setting, and from what I remember I was told that that was intentional.

Could one work around this "feature" via a special "interface" port, say, python-interpreterX.Y, which sets installs_libs to no and otherwise simply depends on pythonX.Y? If the installs_libs setting is a sufficient barrier to "stop" the +universal variant from propagating, no changes to base would be required...

R


More information about the macports-dev mailing list