On Sep 18, 2010, at 6:38 PM, Ryan Schmidt wrote: > Now, in the specific case of py*-numpy and its dependency atlas, it seems > that py*-numpy doesn't link with any libgcc_s.1.dylib so it might not be > affected by this problem. Bear in mind I have not actually experienced any > of the issues we're talking about here, but this is how it was explained to > me.
Fair enough. I understand the linking issue we're talking about, and agree that avoiding it is wise. The only reason I mention the "fix" of deleting the gcc4X variants is that it is so simple & seems to work without unwanted side-effects. numpy's setup.py is designed to easily allow for +universal when using Apple's GCC, but it's not simple when using some other GCC (without the -arch flag). I have found a way to get gcc4X to work as +universal, but it requires 4 patches: 'port' source itself (portutil.tcl), the numpy source, the muniversal portgroup, and of course the numpy Portfile itself. I can go into details and/or provide the actual patches (similar to what I've provided in a past email to the mp-dev list). I think it might be possible to patch the setup.py scripts to use "-m" instead of "-arch", and thus avoid 1 patch; and, the extra numpy source patch might not be necessary with some other tweaking. But, the other 2 patches will still be required. Unlike some ports, numpy is quite stubborn when it comes to letting the user determine the arch type to compile for when not using Apple's GCC; I don't know if it was designed that way intentionally, but the result is quite frustrating from my (as an end-user) perspective. - MLD _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
