[Numpy-discussion] numarray patch: use Apple's vecLib on Mac OS X

Chris Barker Chris.Barker at noaa.gov
Mon Nov 22 16:15:03 CST 2004

Hi all,

I forwarded this thread to Bob Ippolito, the original author of that 
patch. He's not on this list. I do suggest that any questions about OS-X 
be sent to the Pythonmac-SIG list, as there are some folks there that 
really know what they are doing. Anyway, here's his comments:

Bob Ippolito wrote:

Two things:
1) Apple can't (or rather, won't ever) change their framework location.
2) Darwin might be Darwin and not Mac OS X, which won't have vecLib.
3) Checking for both is silly, because you won't reasonably ever have 
the path to vecLib on a non-Darwin platform.. and if you somehow do, 
it'll probably work anyway.

I can give more flexible code with regard to locating frameworks in an 
identical manner to what gcc and dyld do, but that is only going to be 
applicable if you work at Apple, or you are building against an SDK, 
neither of which happen very often in practice.  With regard to building 
against a SDK, the API used by Numeric that is provided by vecLib isn't 
going to change, ever, unless Numeric wants more stuff that is provided 
only in OS X 10.4+, for example.  This would be an issue when and if it 
happens, but in that case you would probably link against the NEW name 
(Accelerate.framework).  I'm not sure if the vecLib API is supported by 
OS X 10.1, but someone else is going to have to care about that because 
I sure don't.

Alternate linkers isn't really a concern because the three command-line 
compilers that matter probably all support the -framework flag.  Apple's 
GCC (obviously..) and IBM's XLC (according to Robert) certainly do, and 
more likely than not, MetroWerks CodeWarrior also does (someone else 
would have to confirm this).  If Fink or Gentoo ships some purely 
GNU-based compiler/linker that doesn't support -framework, I'd consider 
that a bug.  I'm not sure how they'd get many things to compile 
correctly without it, unless they're emulating it by specifying paths 
directly to the Mach-O MH_DYLIB files 
(/System/Library/Frameworks/vecLib.framework/vecLib, for example) PLUS 
using non-framework-style header paths everywhere, since 
<vecLib/vecLib.h> would never work if you -I to anywhere in the 
framework tree.  Does an unpatched GNU toolchain even understand Mach-O 
in the first place?  Most likely a non-issue in any case, but I'm not 
about to Finkify any machine to test that theory.

In summary, I wrote the patch in that way for the specific reason of 
doing it as correctly as possible without overcomplicating things.  I 
hope that people would trust that I know what I'm doing.

Christopher Barker, Ph.D.
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

More information about the Numpy-discussion mailing list