gfortran cannot link lapack and blas in obs

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

gfortran cannot link lapack and blas in obs

Xing
Dear all,

I'm packaging a program (gMultiwfn) which uses lapack and blas. It can
compile without any problem by using './configure && make install'
directly. However when I was packaging it on OBS, the lapcak and blas
cannot be found by gfortran and the error is:

[   57s] gfortran -O3 -std=legacy -fopenmp  -llapack -lblas  -o Multiwfn Multiwfn-Lebedev-Laikov.o Multiwfn-DFTxclib.o Multiwfn-define.o Multiwfn-util.o Multiwfn-function.o Multiwfn-sub.o Multiwfn-fileIO.o Multiwfn-spectrum.o Multiwfn-DOS.o Multiwfn-wfn.o Multiwfn-population.o Multiwfn-compana.o Multiwfn-bondana.o Multiwfn-topology.o Multiwfn-excittransana.o Multiwfn-otherfunc.o Multiwfn-otherfunc2.o Multiwfn-surfana.o Multiwfn-procgriddata.o Multiwfn-AdNDP.o Multiwfn-fuzzyana.o Multiwfn-CDA.o Multiwfn-basinana.o Multiwfn-atmraddens.o
[   57s] Multiwfn-util.o: In function `__util_MOD_diaggemat':
[   57s] util.f90:(.text+0x36a7): undefined reference to `dgeev_'
[   57s] Multiwfn-util.o: In function `__util_MOD_diagsymat':
[   57s] util.f90:(.text+0x3a42): undefined reference to `dsyev_'
[   57s] collect2: error: ld returned 1 exit status
[   57s] Makefile:392: recipe for target 'Multiwfn' failed
[   57s] make[1]: *** [Multiwfn] Error 1
[   57s] make[1]: Leaving directory '/home/abuild/rpmbuild/BUILD/gMultiwfn-3.3.9-0/build/src'
[   57s] Makefile:356: recipe for target 'all-recursive' failed
[   57s] make: *** [all-recursive] Error 1
[   57s] error: Bad exit status from /var/tmp/rpm-tmp.bHBPuv (%build)

where dgeev_ and dsyev_ are the functions in lapack. Multiwfn-*.o are
the obj files just compiled by gfortran.

I did require lapack-devel and blas-devel and the -llapack and -lblas
options were checked by the configure script (using gcc I think)
(Installaton of libblas and liblapack:)

[   14s] [66/107] cumulate libblas3-3.5.0-8.2
...
[   14s] [68/107] cumulate blas-devel-3.5.0-8.2
...
[   14s] [84/107] cumulate lapack-devel-3.5.0-8.2
...
[   14s] [84/107] cumulate lapack-devel-3.5.0-8.2

(checking -lblas and -llapack using gcc):

[   30s] checking for Fortran 77 libraries of gfortran...  -L/usr/lib64/gcc/x86_64-suse-linux/4.8 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.. -lgfortran -lm -lquadmath
[   30s] checking for gcc... gcc
[   30s] checking whether we are using the GNU C compiler... yes
[   30s] checking whether gcc accepts -g... yes
[   30s] checking for gcc option to accept ISO C89... none needed
[   30s] checking whether gcc understands -c and -o together... yes
[   30s] checking for dummy main to link with Fortran 77 libraries... none
[   30s] checking for Fortran 77 name-mangling scheme... lower case, underscore, no extra underscore
[   31s] checking if sgemm_ is being linked in already... no
[   31s] checking for sgemm_ in -lopenblas... no
[   31s] checking for ATL_xerbla in -latlas... no
[   31s] checking for sgemm_ in -lblas... yes
[   31s] checking for dgemm_ in -ldgemm... no
[   31s] checking for sgemm_ in -lmkl_gf_lp64... no
[   31s] checking for sgemm_ in -lmkl... no
[   31s] checking for sgemm_ in -framework vecLib... no
[   31s] checking for sgemm_ in -lcxml... no
[   31s] checking for sgemm_ in -ldxml... no
[   31s] checking for sgemm_ in -lscs... no
[   31s] checking for sgemm_ in -lcomplib.sgimath... no
[   31s] checking for sgemm_ in -lblas... (cached) yes
[   31s] checking for sgemm_ in -lessl... no
[   31s] checking for sgemm_ in -lblas... (cached) yes
[   32s] checking for cheev_... no
[   32s] checking for cheev_ in -llapack... yes
[   32s] checking for a BSD-compatible install... /usr/bin/install -c
[   32s] checking whether build environment is sane... yes
[   32s] checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
[   32s] checking for gawk... gawk
[   32s] checking whether make sets $(MAKE)... yes
[   32s] checking for style of include used by make... GNU
[   32s] checking whether make supports nested variables... yes
[   32s] checking dependency style of gcc... none

Really confusing for me...Is there any special caution to use gfortran
in OBS?

Thanks and best wishes,
Xing

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gfortran cannot link lapack and blas in obs

Andrei Borzenkov
30.04.2017 08:17, Xing пишет:

> Dear all,
>
> I'm packaging a program (gMultiwfn) which uses lapack and blas. It can
> compile without any problem by using './configure && make install'
> directly. However when I was packaging it on OBS, the lapcak and blas
> cannot be found by gfortran and the error is:
>
> [   57s] gfortran -O3 -std=legacy -fopenmp  -llapack -lblas  -o Multiwfn
> Multiwfn-Lebedev-Laikov.o Multiwfn-DFTxclib.o Multiwfn-define.o
> Multiwfn-util.o Multiwfn-function.o Multiwfn-sub.o Multiwfn-fileIO.o
> Multiwfn-spectrum.o Multiwfn-DOS.o Multiwfn-wfn.o Multiwfn-population.o
> Multiwfn-compana.o Multiwfn-bondana.o Multiwfn-topology.o
> Multiwfn-excittransana.o Multiwfn-otherfunc.o Multiwfn-otherfunc2.o
> Multiwfn-surfana.o Multiwfn-procgriddata.o Multiwfn-AdNDP.o
> Multiwfn-fuzzyana.o Multiwfn-CDA.o Multiwfn-basinana.o
> Multiwfn-atmraddens.o

Libraries should come after object modules that reference them. Fix the
order in your makefile.

> [   57s] Multiwfn-util.o: In function `__util_MOD_diaggemat':
> [   57s] util.f90:(.text+0x36a7): undefined reference to `dgeev_'
> [   57s] Multiwfn-util.o: In function `__util_MOD_diagsymat':
> [   57s] util.f90:(.text+0x3a42): undefined reference to `dsyev_'
> [   57s] collect2: error: ld returned 1 exit status
> [   57s] Makefile:392: recipe for target 'Multiwfn' failed
> [   57s] make[1]: *** [Multiwfn] Error 1
> [   57s] make[1]: Leaving directory
> '/home/abuild/rpmbuild/BUILD/gMultiwfn-3.3.9-0/build/src'
> [   57s] Makefile:356: recipe for target 'all-recursive' failed
> [   57s] make: *** [all-recursive] Error 1
> [   57s] error: Bad exit status from /var/tmp/rpm-tmp.bHBPuv (%build)
>
> where dgeev_ and dsyev_ are the functions in lapack. Multiwfn-*.o are
> the obj files just compiled by gfortran.
>
> I did require lapack-devel and blas-devel and the -llapack and -lblas
> options were checked by the configure script (using gcc I think)
> (Installaton of libblas and liblapack:)
>
> [   14s] [66/107] cumulate libblas3-3.5.0-8.2
> ...
> [   14s] [68/107] cumulate blas-devel-3.5.0-8.2
> ...
> [   14s] [84/107] cumulate lapack-devel-3.5.0-8.2
> ...
> [   14s] [84/107] cumulate lapack-devel-3.5.0-8.2
>
> (checking -lblas and -llapack using gcc):
>
> [   30s] checking for Fortran 77 libraries of gfortran...
> -L/usr/lib64/gcc/x86_64-suse-linux/4.8
> -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64
> -L/usr/lib/../lib64
> -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib
> -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.. -lgfortran -lm -lquadmath
> [   30s] checking for gcc... gcc
> [   30s] checking whether we are using the GNU C compiler... yes
> [   30s] checking whether gcc accepts -g... yes
> [   30s] checking for gcc option to accept ISO C89... none needed
> [   30s] checking whether gcc understands -c and -o together... yes
> [   30s] checking for dummy main to link with Fortran 77 libraries... none
> [   30s] checking for Fortran 77 name-mangling scheme... lower case,
> underscore, no extra underscore
> [   31s] checking if sgemm_ is being linked in already... no
> [   31s] checking for sgemm_ in -lopenblas... no
> [   31s] checking for ATL_xerbla in -latlas... no
> [   31s] checking for sgemm_ in -lblas... yes
> [   31s] checking for dgemm_ in -ldgemm... no
> [   31s] checking for sgemm_ in -lmkl_gf_lp64... no
> [   31s] checking for sgemm_ in -lmkl... no
> [   31s] checking for sgemm_ in -framework vecLib... no
> [   31s] checking for sgemm_ in -lcxml... no
> [   31s] checking for sgemm_ in -ldxml... no
> [   31s] checking for sgemm_ in -lscs... no
> [   31s] checking for sgemm_ in -lcomplib.sgimath... no
> [   31s] checking for sgemm_ in -lblas... (cached) yes
> [   31s] checking for sgemm_ in -lessl... no
> [   31s] checking for sgemm_ in -lblas... (cached) yes
> [   32s] checking for cheev_... no
> [   32s] checking for cheev_ in -llapack... yes
> [   32s] checking for a BSD-compatible install... /usr/bin/install -c
> [   32s] checking whether build environment is sane... yes
> [   32s] checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
> [   32s] checking for gawk... gawk
> [   32s] checking whether make sets $(MAKE)... yes
> [   32s] checking for style of include used by make... GNU
> [   32s] checking whether make supports nested variables... yes
> [   32s] checking dependency style of gcc... none
>
> Really confusing for me...Is there any special caution to use gfortran
> in OBS?
>
> Thanks and best wishes,
> Xing
>

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gfortran cannot link lapack and blas in obs

Xing
Thanks! It works after changing the order.
Now I'm confused by the fact that the "wrong" order works in a "normal"
environment (outside the OSC)...

On 04/30/2017 02:09 AM, Andrei Borzenkov wrote:

> 30.04.2017 08:17, Xing пишет:
>> Dear all,
>>
>> I'm packaging a program (gMultiwfn) which uses lapack and blas. It can
>> compile without any problem by using './configure && make install'
>> directly. However when I was packaging it on OBS, the lapcak and blas
>> cannot be found by gfortran and the error is:
>>
>> [   57s] gfortran -O3 -std=legacy -fopenmp  -llapack -lblas  -o Multiwfn
>> Multiwfn-Lebedev-Laikov.o Multiwfn-DFTxclib.o Multiwfn-define.o
>> Multiwfn-util.o Multiwfn-function.o Multiwfn-sub.o Multiwfn-fileIO.o
>> Multiwfn-spectrum.o Multiwfn-DOS.o Multiwfn-wfn.o Multiwfn-population.o
>> Multiwfn-compana.o Multiwfn-bondana.o Multiwfn-topology.o
>> Multiwfn-excittransana.o Multiwfn-otherfunc.o Multiwfn-otherfunc2.o
>> Multiwfn-surfana.o Multiwfn-procgriddata.o Multiwfn-AdNDP.o
>> Multiwfn-fuzzyana.o Multiwfn-CDA.o Multiwfn-basinana.o
>> Multiwfn-atmraddens.o
>
> Libraries should come after object modules that reference them. Fix the
> order in your makefile.
>
>> [   57s] Multiwfn-util.o: In function `__util_MOD_diaggemat':
>> [   57s] util.f90:(.text+0x36a7): undefined reference to `dgeev_'
>> [   57s] Multiwfn-util.o: In function `__util_MOD_diagsymat':
>> [   57s] util.f90:(.text+0x3a42): undefined reference to `dsyev_'
>> [   57s] collect2: error: ld returned 1 exit status
>> [   57s] Makefile:392: recipe for target 'Multiwfn' failed
>> [   57s] make[1]: *** [Multiwfn] Error 1
>> [   57s] make[1]: Leaving directory
>> '/home/abuild/rpmbuild/BUILD/gMultiwfn-3.3.9-0/build/src'
>> [   57s] Makefile:356: recipe for target 'all-recursive' failed
>> [   57s] make: *** [all-recursive] Error 1
>> [   57s] error: Bad exit status from /var/tmp/rpm-tmp.bHBPuv (%build)
>>
>> where dgeev_ and dsyev_ are the functions in lapack. Multiwfn-*.o are
>> the obj files just compiled by gfortran.
>>
>> I did require lapack-devel and blas-devel and the -llapack and -lblas
>> options were checked by the configure script (using gcc I think)
>> (Installaton of libblas and liblapack:)
>>
>> [   14s] [66/107] cumulate libblas3-3.5.0-8.2
>> ...
>> [   14s] [68/107] cumulate blas-devel-3.5.0-8.2
>> ...
>> [   14s] [84/107] cumulate lapack-devel-3.5.0-8.2
>> ...
>> [   14s] [84/107] cumulate lapack-devel-3.5.0-8.2
>>
>> (checking -lblas and -llapack using gcc):
>>
>> [   30s] checking for Fortran 77 libraries of gfortran...
>> -L/usr/lib64/gcc/x86_64-suse-linux/4.8
>> -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../lib64 -L/lib/../lib64
>> -L/usr/lib/../lib64
>> -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/lib
>> -L/usr/lib64/gcc/x86_64-suse-linux/4.8/../../.. -lgfortran -lm -lquadmath
>> [   30s] checking for gcc... gcc
>> [   30s] checking whether we are using the GNU C compiler... yes
>> [   30s] checking whether gcc accepts -g... yes
>> [   30s] checking for gcc option to accept ISO C89... none needed
>> [   30s] checking whether gcc understands -c and -o together... yes
>> [   30s] checking for dummy main to link with Fortran 77 libraries... none
>> [   30s] checking for Fortran 77 name-mangling scheme... lower case,
>> underscore, no extra underscore
>> [   31s] checking if sgemm_ is being linked in already... no
>> [   31s] checking for sgemm_ in -lopenblas... no
>> [   31s] checking for ATL_xerbla in -latlas... no
>> [   31s] checking for sgemm_ in -lblas... yes
>> [   31s] checking for dgemm_ in -ldgemm... no
>> [   31s] checking for sgemm_ in -lmkl_gf_lp64... no
>> [   31s] checking for sgemm_ in -lmkl... no
>> [   31s] checking for sgemm_ in -framework vecLib... no
>> [   31s] checking for sgemm_ in -lcxml... no
>> [   31s] checking for sgemm_ in -ldxml... no
>> [   31s] checking for sgemm_ in -lscs... no
>> [   31s] checking for sgemm_ in -lcomplib.sgimath... no
>> [   31s] checking for sgemm_ in -lblas... (cached) yes
>> [   31s] checking for sgemm_ in -lessl... no
>> [   31s] checking for sgemm_ in -lblas... (cached) yes
>> [   32s] checking for cheev_... no
>> [   32s] checking for cheev_ in -llapack... yes
>> [   32s] checking for a BSD-compatible install... /usr/bin/install -c
>> [   32s] checking whether build environment is sane... yes
>> [   32s] checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
>> [   32s] checking for gawk... gawk
>> [   32s] checking whether make sets $(MAKE)... yes
>> [   32s] checking for style of include used by make... GNU
>> [   32s] checking whether make supports nested variables... yes
>> [   32s] checking dependency style of gcc... none
>>
>> Really confusing for me...Is there any special caution to use gfortran
>> in OBS?
>>
>> Thanks and best wishes,
>> Xing
>>
>

--
Thanks and best wishes,
Xing
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: gfortran cannot link lapack and blas in obs

Andreas Schwab-2
On Apr 30 2017, Xing <[hidden email]> wrote:

> Now I'm confused by the fact that the "wrong" order works in a "normal"
> environment (outside the OSC)...

Because the build enviroment has SUSE_ASNEEDED=1 which causes the linker
to default to --as-needed.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]