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

 
 

bug #31046: Check for lsame obsolete

Submitted by:  None
Submitted on:  Wed 15 Sep 2010 07:38:14 PM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: FixedAssigned to: Jaroslav Hajek <highegg>
Originator Name: Thomas TreichlOriginator Email: -unavailable-
Open/Closed: ClosedRelease: dev
Operating System: Mac OS

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>In charge of this item.
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>In charge of this item.
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>In charge of this item.
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>In charge of this item.
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>
Project 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>In charge of this item.
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 File(s):
   
   
Comment:
   

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

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 24 Sep 2010 07:41:18 PM UTChigheggStatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Sat 18 Sep 2010 04:47:07 AM UTChigheggStatusNeed Info=>Confirmed
      Assigned toNone=>highegg
    Thu 16 Sep 2010 03:36:17 PM UTCNoneAttached File-=>Added ax_blas.diff, #21474
    Thu 16 Sep 2010 07:07:55 AM UTCjweStatusNone=>Need Info
      Carbon-Copy-=>Added highegg

    Back to the top


    Powered by Savane 3.1-cleanup