numpy & non-Apple gcc?

[Ryan Schmidt]

On Sep 17, 2010, at 14:36, Michael Dickens wrote:
> 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)

Actually, what I was referring to is the case that:

 * library A requires fortran, and therefore specifies configure.compiler macports-gcc-4.4 or some other MacPorts GCC
 * this causes library A to not only use that compiler's fortran, but also use that compiler's libgcc_s.1.dylib, for example:

$ otool -L /opt/local/lib/liblapack.dylib
/opt/local/lib/liblapack.dylib:
	/opt/local/lib/liblapack.dylib (compatibility version 0.0.0, current version 0.0.0)
	/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 219.0.0)
	/opt/local/lib/libatlas.dylib (compatibility version 0.0.0, current version 0.0.0)
	/opt/local/lib/gcc44/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
	/opt/local/lib/gcc44/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) <---
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

 * program B wants to link with library A; it must then use the same compiler otherwise it would link with a different libgcc_s.1.dylib which might not be compatible

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.