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