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

[Ben Abbott]

On Feb 6, 2011, at 9:59 AM, Richard Campbell wrote:

> On Feb 4, 2011, at 11:33 AM, bpabbott wrote:
> 
>> On Feb 04, 2011, at 09:58 AM, Jarno Rajahalme <address@hidden> 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
>>> 
>>> 
>>> 
>>> 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 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.hin 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
>> 
>> I've attempted to convert the diffs into changesets. They are attached.
>> 
>> Jarno/Richard,
>> 
>> Please try use apply these and confirm they work as intended.
>> 
>> John,
>> 
>> I'm skittish about pushing changes to the build process. I'll wait for you 
>> to approve or to push these yourself.
>> 
>> Ben
>> 
>> <changeset-blaswrap.patch><changeset-configure.patch>
> 
> John, Ben - 
> 
> Have either of you pushed this patch into the repository yet? I don't see it 
> there.
> 
> Campbell

Not yet.

As I mentioned above, I'm skittish about pushing changes to the build process. 
I'd like to hear John's comments before pushing.

Ben