octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OSX blas wrapper for release (Re: plans for release)


From: Richard Campbell
Subject: Re: OSX blas wrapper for release (Re: plans for release)
Date: Fri, 4 Feb 2011 10:47:28 -0500

On Feb 4, 2011, at 9:58 AM, Jarno Rajahalme wrote:

> 
> On Feb 3, 2011, at 22:24 , ext John W. Eaton wrote:
> 
>> On  3-Feb-2011, Richard Campbell wrote:
>> 
>> | I'd like to see Jarno's blaswrap.c included in the Octave source, and used
>> | automatically when the user runs ./configure for a 64-bit Octave on a 
>> machine
>> | where the Apple-provided BLAS is the only one detected.
>> 
>> It would probably be good to also verify that the detected BLAS won't
>> work, so that if it is fixed in the future the wrapper won't be
>> needed.
>> 
> 
> After some deliberation I thought the best place for the wrapper is 
> libcruft/misc/. This avoids managing an additional dylib, and is a no-op, 
> when the wrapper is not needed.
> 
> Here is a patch to configure.ac and libcruft/misc/module.mk that:
> 
> 0) removes -arch flags from FLTK flags to allow compilation with non-Apple GCC
> 1) if blas is found to be incompatible, tries again with -ff2c
> 2) if it is still incompatible, and platform is darwin, compiles 
> libcruft/misc/blaswrap.c, and tries with that
> - if successful, defines USE_BLASWRAP, so that libcruft will be built to 
> contain the wrapper.
> 
> Steps to apply:
> 
> 1. Patch configure.ac and libcruft/misc/module.mk:
> 
> $ patch -p 1 < blaswrap.patch
> 
> <blaswrap.patch>
> 
> The same patch also updates libcruft/misc/module.mk to include blaswrap.c
> 
> 
> 2. Place blaswrap.c into libcruft/misc
> 
> $ cp blaswrap.c /libcruft/misc/.
> 
> <blaswrap.c>
> 
> blaswrap.c is updated to work from within libcruft (included, save as 
> libcruft/misc/blaswrap.c)
> 
> The updated wrapper should work also with 32-bit builds. But since the 
> "-ff2c" option is tested first, the wrapper will NOT be used on 32-bit builds.
> 
> 
> 3. Have your config.h.in updated:
> 
> $ ./autogen.sh
> 
> This works only for the development version. For a snapshot, you need to do 
> this manually. Ddd these lines to config.h.in after line 2203:
> 
> /* Define this if BLAS functions need to be wrapped (potentially needed for
>  OSX only). */
> undef USE_BLASWRAP
> 
> Please note that if your config.h.in does not get updated (see above), the 
> configure will succeed, but the wrapper will be ignored during build, likely 
> causing a crash.
> 
> 
> 4. ./configure <your config options>
> 
> Note that there is no need for any blas options here.
> 
> 
> 5. make -j2 check
> 
> If you built on 32-bit OSX, your FFLAGS should now have "-ff2c", and 
> BLAS_LIBS should contain "-framework vecLib"
> 
> If you built on 64-bit OSX, config.h should define USE_BLASWRAP, and 
> BLAS_LIBS should contain "-framework vecLib".
> 
> Additionally, after you make octave, you should see that libcruft defines 
> ("T") the symbol _cdotu_, while without the wrapper it remains undefined 
> ("U"):
> 
> $ nm -g libcruft/.libs/libcruft.dylib | grep -i _cdotu_
> 00000000000821e0 T _cdotu_
> $ 
> 
> 
> I have tested this on OSX 10.6.6, with gcc-4.2 and gcc-mp-4.5, building 
> 64-bit only. Someone else should test this on a 32-bit build.
> 
> NOTE: if you have atlas installed, it will likely be used instead of the 
> wrapper. I think this is as it should be.
> 
> Finally, as I have never pushed anything on Octave source base, I'd be happy 
> if someone else does it.
> 
>  Jarno
> 

Jarno,

Great, thanks for your effort. I hope this makes it into the release this 
weekend. I also haven't figured out how to make a Mercurial changeset and I 
don't think I will in time. Anyone?

Campbell

reply via email to

[Prev in Thread] Current Thread [Next in Thread]