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