Resulting libflame.a misses symbol lsamen

[norman....@gmail.com]

Hey there,

maybe I got something wrong. I was able to build libflame successfully from the latest checkout, but can't use it later cause it misses the function "lsamen" which does actually occur in the sources. O_o

My system:

Linux cip6 3.11.10-29-desktop #1 SMP PREEMPT Thu Mar 5 16:24:00 UTC 2015 (338c513) x86_64 x86_64 x86_64 GNU/Linux

gcc version 4.8.1 20130909 [gcc-4_8-branch revision 202388] (SUSE Linux)

My configure:

./configure --enable-builtin-blas --enable-lapack2flame

make
make install

Afterwards:

nm libflame.a | grep lsamen

returns nothing, whereas for acml:

nm libacml.a | grep lsamen

lsamen_cw.o:
0000000000000000 T lsamen
U lsamen_
lsamen.o:
0000000000000000 T lsamen_

Any idea?

[Field G. Van Zee]

Norman,

Please see the response below from the author of the lapack compatibility layer.

It appears there is no way to include support your link needs while keeping
everything in C. (Kyungjoo can correct me if my interpretation is mistaken.)

How/why does your application need lsamen_()?

Field


On 09/17/15 15:43, Kyungjoo Kim wrote:
> Hi Field,
>
> lsamen is a string comparing routine for 'n' characters. This routine is
> not inter-operatible with Fortran as fortran string structure is completely
> different from C-based string (lsame is working as it only compares a
> single character). If I remember correct, lsamen is only used in the lapack
> test routines (never used inside of lapack lib). So, if we want to test
> lapack test suite (fortran) with libflame, lsamen should be included as a
> fortran file (not C file).
>
> Those 'other' directories include files that are not inter-operatible with
> C and fortran (it is tricky).
>
> I would first ask the reason to use the function. If the reason is purely
> for testing lapack test suite, then there is no way but include the file as
> a fortran file.
>
> Best, Kyungjoo Kim
>
>
> Center for Computing Research,
> Sandia National Labs,
> P.O. Box 5800, MS 1320,
> Albuquerque, NM 87185-1320.
>
>
>
>
> On Sep 17, 2015, at 2:17 PM, Field G. Van Zee <fi...@cs.utexas.edu
> <mailto:fi...@cs.utexas.edu>> wrote:
>
>> Kyungjoo,
>>
>> Did you mean for the following files to reside in a directory that is
>> skipped over by the libflame build system?
>>
>> $ ls src/map/lapack2flamec/f2c/install/*/other/
>> src/map/lapack2flamec/f2c/install/static/other/: dlamchtst.c ilaver.c
>> lsametst.c secondtst.c xerbla_array.c dsecndtst.c lsamen.c s_kat.c
>> slamchtst.c
>>
>> src/map/lapack2flamec/f2c/install/util/other/: abort_.c erf_.c
>> getarg_.c i_ceiling.c lbitbits.c s_cat.c signbit.c derf_.c
>> erfc_.c getenv_.c i_indx.c lbitshft.c s_stop.c derfc_.c
>> etime_.c h_indx.c i_len.c qbitbits.c sig_die.c dtime_.c
>> f77_aloc.c h_len.c i_len_trim.c qbitshft.c signal_.c
>>
>> This user needs one of the routines that exist there. (Recall that files
>> in directories named 'other' are currently skipped, though I am in the
>> process of renaming those that truly need to be skipped to 'old'.)
>>
>> I tried to enable those directories, but I got some compiler errors that
>> make me think you did not prep those files for inclusion in libflame.
>>
>> Field
>>
>> -------- Forwarded Message -------- Subject: [libflame-discuss] Resulting
>> libflame.a misses symbol lsamen Date: Thu, 17 Sep 2015 00:33:41 -0700
>> (PDT) From: norman....@gmail.com <mailto:norman....@gmail.com>
>> To: libflame-discuss <libflame...@googlegroups.com
>> <mailto:libflame...@googlegroups.com>>

>> -- You received this message because you are subscribed to the Google
>> Groups "libflame-discuss" group. To unsubscribe from this group and stop
>> receiving emails from it, send an email to
>> libflame-discu...@googlegroups.com
>> <mailto:libflame-discu...@googlegroups.com>. To post to this
>> group, send email to libflame...@googlegroups.com
>> <mailto:libflame...@googlegroups.com>. Visit this group at
>> http://groups.google.com/group/libflame-discuss. For more options, visit
>> https://groups.google.com/d/optout.
>>
>>
>>
>

[NORMAN GEIST]

Hey,

thanks for your attention. The problem came up when I tried to build ScalaPack(2.0.2) based on LibFLame as an replacement for ACML.

[Field G. Van Zee]

Norman,

Unfortunately, we will not be able to help you out with this. There are two
primary reasons, which are part philosophical and part technical:

- It appears that lsamen_() is not officially part of LAPACK, but rather part
of LAPACK's test suite, thus, it is outside of the scope of functionality for
libflame's LAPACK compatibility layer.

- According to Kyungjoo, one would need to compile lsamen.o from Fortran (not
C that was converted from Fortran). Since libflame contains only C source
code, we would not be able to accommodate this routine.

Potential workarounds:

- You could simply manually compile this source file from LAPACK into your
application. That should satisfy your linker.

- You could also consider using Elemental instead of Scalapack.

best regards,
Field

[NORMAN GEIST]

Thanks for the insight. In the meantime I was able to find a replacement for ACML with OpenBlas. Same performance and full LAPACK implemented-

But, I'd like to have a look on Elemental as you suggested.

Thanks a lot

Norman

[Kyungjoo Kim]

Dear  Norman:

ScaLapack source files do not use lsamen routine, but the TEST code uses the utility function. Unfortunately I do not find an appropriate way to handle a fortran string in the C code (lsamen). At this moment, you probably need to put the lsamen into Scalapack TEST directory. Field, do you have a better idea ? 

Best,

Kyungjoo Kim

Center for Computing Research,

Sandia National Labs, 

P.O. Box 5800, MS 1320, 

Albuquerque, NM 87185-1320.

[Field G. Van Zee]

On 09/21/15 12:07, Kyungjoo Kim wrote:
> Dear Norman:
>
>
> ScaLapack source files do not use lsamen routine, but the TEST code uses the
> utility function. Unfortunately I do not find an appropriate way to handle a
> fortran string in the C code (lsamen). At this moment, you probably need to
> put the lsamen into Scalapack TEST directory. Field, do you have a better idea ?

I don't. This seems like the most reasonable thing to do.

Thanks for chiming in!

Field

>
>
>
> Best,
> Kyungjoo Kim
>
>
> Center for Computing Research,
> Sandia National Labs,
> P.O. Box 5800, MS 1320,
> Albuquerque, NM 87185-1320.
>
>
>
>
> On Sep 18, 2015, at 6:06 AM, NORMAN GEIST <norman....@gmail.com

> <mailto:norman....@gmail.com>> wrote:
>
>> thanks for your attention. The problem came up when I tried to build
>> ScalaPack(2.0.2) based on LibFLame as an replacement for ACML.
>