numpy & non-Apple gcc?

[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).
                       Jack

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