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

[Richard Campbell]

On Feb 4, 2011, at 11:40 AM, bpabbott wrote:

> On Feb 04, 2011, at 11:07 AM, Richard Campbell <address@hidden> wrote:
> 
>> On Feb 4, 2011, at 10:47 AM, Richard Campbell wrote:
>> 
>> > 
>> > 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
>> 
>> 
>> Okay, I followed the instructions in the Octave pdf to make a Mercurial 
>> changeset. It's attached.
>> 
>> I don't think it actually puts the blaswrap.c file in the source tree, 
>> though.
>> 
>> Campbell
>  
> You can add the new file using the syntax
> 
>       hg add <filename>
> 
> Also the Changelog entries need to be included in ...
> 
>       ./libcruft/ChangeLog
>       ./ChangeLog
> 
> While you were working on your changeset, I attempted one of my own Mine is 
> split into two, but there is no need for that (I did it for my own 
> convenience).
> 
> Ben
> 

Ben,

Jordi showed me what I did wrong with "hg add", but I didn't mess with the 
changelog. I'll defer to your version of the patch - I've got to work on other 
things. Thanks all for getting it done, though.

Campbell