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