numpy & non-Apple gcc?

[Michael Feiri]

Am 21.09.2010 um 15:50 schrieb Jack Howarth:

> On Tue, Sep 21, 2010 at 09:40:27AM -0400, Michael Dickens wrote:
>> 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?
>
> Michael,
>   You do understand that for FSF gcc 4.5 and later, we no longer  
> build the versioned libgcc_s 10.4/10.5 stubs and only
> the system libgcc_s versioned stubs are used? Symbols from FSF gcc's  
> libgcc that not listed in the system versioned libgcc_s stubs
> are provided via the new versioned libgcc_ext shared library. So the  
> best approach would be to use gcc45 or later
> and make sure that you add -lgcc_ext.[10.4,10.5] to the linkage if  
> using Apple's compilers to link the final binaries
> (if mixing FSF gcc and Apple gcc object code).

We also have llvm-gfortran-4.2 available in macports as part of the  
llvm-gcc42 port. This version of gfortran is based on Apples branch of  
gcc42 and uses the latest llvm for code generation. It should be the  
safest option because it uses the same libgcc linking rules as Apples  
gcc42. No libgcc_ext or other workarounds required.

MfG, Michael