I used your second patch that you've posted. The output of the ./configure script on my Mac machine looks very good, see yourself:

checking if sgemm_ is being linked in already... no
checking for ATL_xerbla in -latlas... no
checking for sgemm_ in -lblas... yes
checking for dgemm_ in -ldgemm... no
checking for sgemm_ in -lmkl... no
checking for sgemm_ in -framework vecLib... yes
checking whether LSAME is called correctly from Fortran... yes
checking whether ISAMAX is called correctly from Fortran... yes
checking whether SDOT is called correctly from Fortran... yes
checking whether DDOT is called correctly from Fortran... yes
checking whether CDOTU is called correctly from Fortran... yes
checking whether ZDOTU is called correctly from Fortran... yes

Aha, I see. AC_CHECK_FUNC autocaches its result, and it does a poor job here. I think the proper fix is to replace AC_CHECK_FUNC with AC_TRY_LINK_FUNC (which does not cache). I'll try to do it and report it upstream (since ax_blas.m4 does not come from Octave).

No, problem on your side not mine. Check this output of ./configure and I try to explain what happens:

checking for sgemm_... no
checking for ATL_xerbla in -latlas... no
checking for sgemm_ in -lblas... yes
checking for dgemm_ in -ldgemm... no
checking for sgemm_ in -lmkl... no
checking for sgemm_... (cached) no
checking for sgemm_ in -lcxml... no
checking for sgemm_ in -ldxml... no
checking for sgemm_ in -lscs... no
checking for sgemm_ in -lcomplib.sgimath... no
checking for sgemm_ in -lblas... (cached) yes
checking for sgemm_ in -lessl... no
checking for sgemm_ in -lblas... (cached) yes

And that is what happens:
sgemm_ per default: no
sgemm_ in Atlas: no
sgemm_ in blas: YES (BUT IT IS NOT WORKING)
sgemm_ in Intel: no
sgemm_ in Apple's vecLib: !CACHED! from test "sgemm_ per default" and result was no (there was no modification but the LIBS variable) - the test was not done once again
sgemm_ in cxml: no
sgemm_ in dxml: no
sgemm_ in -lscs: no
sgemm_ in -lcomplib.sgimath: no
sgemm_ in -lblas and -lessl: NOT WORKING
sgemm_ in -lblas: !CACHED! AND WORKING THIS TIME

But the first test doesn't try -lblas, it tries whether BLAS is being linked in already. It seems that for some reason, you already have -lblas in LIBS when AX_BLAS is entered. If so, that is probably error on your side.

Here is the output of config.log and I found out, that the flag "-framework vecLib" isn't used anymore on the Mac platform that we used for a very long time. I'm surprised that the compiler finds a -lblas and I wonder where it comes from?! Looks like there have changed some more things that I need to investigate...

Ok, further investigation results follow ;-) Looks like in ax_blas.m4 my new Mac 10.6 now finds "-lblas" before the test for "-framework veclib" is started, that's why "-framework veclib" isn't used anymore. I quickly changed the order of these tests and the results look very good again. A patch file is attached where you can see my modifications.

Please decide for yourselves if this change would be a possible solution?

The test is not checking just to see whether lsame exists, but for whether Fortran functions that return logical values are handled as we expect. At least that's the way I read the test. Maybe Jaroslav can comment, since he wrote the test.

Is lsame not available in either the blas or lapack libraries on your system? I see that it is part of the fortran blas from netlib, but the comments in lsame.f say that it is an auxiliary routine for lapack. It seems odd that it would have been removed completely.

Basically, the test is there to verify that Fortran LOGICALs are passed correctly. Although there is no standard interface, LSAME has been in BLAS since time immemorial and I regard it as a defect of veclib that it is not there. Even if they don't use LSAME, it could still be provided.

it's been a while since I last tried to compile the latest development sources but today I gave it another chance. I was surprised that the sources haven't changed that much since April 2010, so with little modifications I was able to compile most of the code.

However, I came across the problem that the ./configure script failed because of a check for lsame which isn't there on my Mac's framework veclib - but I also wonder if it is still necessary to test for it: I did a quick