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