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