numpy & non-Apple gcc?

Michael Dickens michaelld at macports.org
Fri Sep 17 12:36:36 PDT 2010


On Sep 17, 2010, at 3:22 PM, Ryan Schmidt wrote:
> AFAIK the differences do still exist and will always exist. The problem as I understand it is if you try to compile library A with compiler X and compile program B (which links with library A) with compiler Y, inexplicable problems can surface, which is why all the science ports are supposed to be standardized to use a single compiler. (All of MacPorts, really, uses a single compiler -- Apple's, but with the science ports, they often need to use fortran, which means non-Apple GCC, and if one port is doing that, then its dependencies should have the option to use that same compiler too.)

Ah; yes.  What you're referring to is the case that:

+ library A required libgfortran (or libgcc)

+ library B required library A -and- libgfortran (or libgcc) as 1st order link libraries (meaning that symbols would end up undefined without linking to both of those libraries)

... we definitely want to make sure that the libgfortran (or libgcc) is the same, otherwise the end results are undefined (competing libraries containing roughly the same ABI).

I think the issues do not arise with numpy, since it does not -directly- rely on libgfortran (or any of the other gcc4X series libraries).  If I do:

% otool -L /opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/numpy/linalg/lapack_lite.so
        /opt/local/lib/liblapack.dylib (compatibility version 0.0.0, current version 0.0.0)
        /opt/local/lib/libptf77blas.dylib (compatibility version 0.0.0, current version 0.0.0)
        /opt/local/lib/libptcblas.dylib (compatibility version 0.0.0, current version 0.0.0)
        /opt/local/lib/libatlas.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

and, that's the only .so module that asks for fortran linking.  So, while I agree in general on the use of the same gcc4X options, I think in this case an exception can be made. - MLD


More information about the macports-users mailing list