bugGNU Octave - Bugs: bug #31046, Check for lsame obsolete

 
 

bug #31046: Check for lsame obsolete

Submitter:  None
Submitted:  Wed 15 Sep 2010 07:38:14 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Build Failure
Status:  Fixed Assigned to:  highegg
Originator Name:  Thomas Treichl Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * dev
Operating System:  * Mac OS Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 24 Sep 2010 07:41:18 PM UTC, comment #10: 

The patch is upstream, I updated Octave's copy of ax_blas.m4.

Jaroslav Hajek <highegg>
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

Anonymous
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.

Jaroslav Hajek <highegg>
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?

Anonymous
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).

Jaroslav Hajek <highegg>
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

Anonymous
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.

Jaroslav Hajek <highegg>
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)

Anonymous
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.

John W. Eaton <jwe>
Group administrator
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.

Jaroslav Hajek <highegg>
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


Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #21474:  ax_blas.diff added by None (1KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jwe
  • -email is unavailable- added by highegg (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-09-24 highegg StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2010-09-18 highegg StatusNeed Info Confirmed
        Assigned toNone highegg
    2010-09-16 None Attached File- Added ax_blas.diff, #21474
    2010-09-16 jwe StatusNone Need Info
        Carbon-Copy- Added highegg

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code