Fri 24 Sep 2010 07:41:18 PM UTC, comment #10:
The patch is upstream, I updated Octave's copy of ax_blas.m4.
|
Tue 21 Sep 2010 05:48:02 PM UTC, comment #9:
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
|
Mon 20 Sep 2010 06:37:24 AM UTC, comment #8:
I made a patch and sent it upstream:
https://savannah.gnu.org/patch/index.php?7320
Please verify that it fixes things for you, I'll wait for possible adjustments by the author and then update Octave sources.
|
Sat 18 Sep 2010 07:34:31 AM UTC, comment #7:
Fine, thanks.
For the records, where all this discussion started: libblas now is part of /usr/lib - at least since MacOSX 10.6 (don't know about 10.5 but I'm sure it was not there with 10.4), cf.
Me@Mac ~$ ls -l /usr/lib/libblas.dylib
lrwxr-xr-x 1 root wheel 112 4 Nov 2009 /usr/lib/libblas.dylib -> ../..//System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/libBLAS.dylib
Me@Mac ~$ ls -l /usr/lib/liblapack.dylib
lrwxr-xr-x 1 root wheel 114 4 Nov 2009 /usr/lib/liblapack.dylib -> ../..//System/Library/Frameworks/Accelerate.framework/Frameworks/vecLib.framework/Versions/Current/libLAPACK.dylib
lsame seems to be part of liblapack.dylib
Me@Mac ~$ nm /usr/lib/liblapack.dylib | grep lsame
000000000041d000 T _lsame
000000000041d000 T lsame
000000000041cd90 T _lsamen
000000000041cd90 T lsamen
and something more is there in libblas.dylib (what means lower cas letter t?)
Me@Mac ~$ nm /usr/lib/libblas.dylib | grep lsame
000000000000a0dd t lsame
but only both together produce a right check result for lsame if the linker flag "-framework vecLib" is given... That's what I understand?
|
Sat 18 Sep 2010 04:47:07 AM UTC, comment #6:
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).
|
Fri 17 Sep 2010 10:01:05 PM UTC, comment #5:
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
-> -lblas is used instead of -framework vecLib
|
Fri 17 Sep 2010 07:40:57 PM UTC, comment #4:
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.
|
Thu 16 Sep 2010 03:36:17 PM UTC, comment #3:
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...
configure:43785: checking whether LSAME is called correctly from Fortran
configure:43808: i386-apple-darwin8.11.1-g95 -o conftest -O -mieee-fp -fforce-addr -I/Applications/Programming/Octave.app/Contents/Resources/include -mieee-fp -L/Applications/Programming/Octave.app/Contents/Resources/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot -Wl,/Developer/SDKs/MacOSX10.6.sdk -Wl,-lexpat conftest.f -lblas -lm >&5
/var/folders/4Z/4ZhcEt0RHjKlYwMVpGf+PE+++TI/-Tmp-//cc022Gqj.s:94:indirect jmp without `*'
/var/folders/4Z/4ZhcEt0RHjKlYwMVpGf+PE+++TI/-Tmp-//cc022Gqj.s:109:indirect jmp without `*'
/var/folders/4Z/4ZhcEt0RHjKlYwMVpGf+PE+++TI/-Tmp-//cc022Gqj.s:124:indirect jmp without `*'
Undefined symbols:
"_lsame_", referenced from:
MAIN in ccRjTMKy.o
MAIN in ccRjTMKy.o
ld: symbol(s) not found
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?
(file #21474)
|
Thu 16 Sep 2010 07:07:55 AM UTC, comment #2:
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.
|
Thu 16 Sep 2010 07:02:56 AM UTC, comment #1:
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.
|
Wed 15 Sep 2010 07:38:14 PM UTC, original submission:
Dear development team,
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
ME@Mac ~/Development/Octave$ grep -re "lsame" *
m4/ax_blas_f77_func.m4: logical lsame,w
m4/ax_blas_f77_func.m4: external lsame
m4/ax_blas_f77_func.m4: w = lsame(c1,c2)
m4/ax_blas_f77_func.m4: w = lsame(c1,c1)
m4/ax_blas_f77_func.m4: ]]),[ax_blas_lsame_fcall_ok=yes],
m4/ax_blas_f77_func.m4: [ax_blas_lsame_fcall_ok=no])
m4/ax_blas_f77_func.m4: AC_MSG_RESULT([$ax_blas_lsame_fcall_ok])
m4/ax_blas_f77_func.m4: if test $ax_blas_lsame_fcall_ok = yes
where I saw that "lsame" exists in the file "ax_blas_f77_func.m4" only. I removed this test an compilation succeeded up to fltk-backend.cc where I got my first error.
Is the check for lsame still necessary?
Best regards
Thomas
|