numpy & non-Apple gcc?

[Keith J. Schultz]

First off I would like to apoligize for sending mails to the
original sender and not the list. It is the first time this has happen.
But, I usually expect that when receiving  mails from a list that the
return path is set to the list. This seems not to be the case. I will try
to be more careful from now on.

I should have been more specific in my first message. 
What I meant was could we get the fortran capabilities or compiler
patched into Apple's or have a fortran compiler in MacPorts offering
similar capabilities, so that other ports do not have similar problems.

If would think the only problem is bootstrapping the gfortran compiler.
But, I do not know the intrinsics of gcc and the gfortran compiler.

regards
	Keith.

Am 21.09.2010 um 15:40 schrieb Michael Dickens:

> 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