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 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
