numpy & non-Apple gcc?
Michael Dickens
michaelld at macports.org
Tue Sep 21 06:40:27 PDT 2010
On Sep 21, 2010, at 4:06 AM, Keith J. Schultz wrote:
> Hi All, Is there not a way to get of make a port for the Apple GCC or add ATLAS support to it? I no it is easier just to adapt the other gcc, but adding the above mentioned functionality would get ride of the other headaches. regards, Keith.
Hi Keith - I assume you meant to reply to the lists instead of just me, so I'm doing that now.
Yes, we -can- make this port work the Apple's GCC. See ticket #24942 < https://trac.macports.org/ticket/24942 > for more info & trial patches. I would truly appreciate some feedback on this potential fix.
The issue is that the numpy developers upstream do not recommend doing using Apple's GCC when using +atlas because the Atlas port is compiled using a different compiler (gcc 43/44/45) & hence links to those GCC libraries, which might conflict with Apple's GCC libraries. We want to keep linked libraries consistent, because the runtime behavior is undefined if multiple libgcc libraries are linked (directly or indirectly) to the same executable -- rhetorical questions to make this point: which libgcc version is loaded and used (can't be both)? Is the loaded one ABI compatible with what all the binaries require?
That said, specifically for numpy 1.5.0, we can use Apple's GCC with +atlas because the only module using Atlas is the linalg one which does not link with any GCC libraries at all.
That said, providing this variant might for work for 1.5.0, but not for 1.5.1 when it comes out since the link requirements might change. So, while we can make a temporary change to allow for this option & thus fix a whole bunch of open related tickets (last count: around 10), maybe we should instead strive for a more generic fix?
Because the changes are so simple for this temporary patch (similar to that in the ticket mentioned above), I'm open to making the small changes required to allow using Apple's GCC so-as to solve folks' immediate issues -- knowing that we need a better solution down the road. I will make these changes later today unless someone greatly objects to me doing so (the port is openmaintainer, after all :). - MLD
More information about the macports-dev
mailing list