Summary: | sci-libs/coinor-utils-2.9.11 USE=lapack - configure: error: user supplied LAPACK library "-lreflapack -lf77blas -lf77blas " does not work | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Beutin <tb> |
Component: | [OLD] Library | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | frp.bissey |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
ebuild patch
build.log config.log build.log of sci-libs/lapack-reference-3.5.0 config.log of sci-libs/coinor-utils-2.9.11 after merging sci-libs/lapack-reference-9999 |
Description
Thomas Beutin
2014-09-21 16:08:41 UTC
Created attachment 385242 [details, diff]
ebuild patch
using this patch everything compiles and installs fine
Which blas, cblas and lapack are you using? Please attach a build.log. --with-lapack-lib linker flags for using package Lapack I don't think this is a good idea. Created attachment 385296 [details]
build.log
# for i in lapack blas cblas ; do eselect $i list ; done Available providers for lapack: [1] atlas [2] atlas-threads [3] reference * Available providers for blas: [1] atlas * [2] atlas-threads [3] openblas-dynamic-int64-threads [4] reference Available providers for cblas: [1] atlas * [2] atlas-threads [3] gsl [4] openblas-dynamic-int64-threads [5] reference (In reply to Thomas Beutin from comment #4) [...] > Available providers for lapack: > [1] atlas > [2] atlas-threads > [3] reference * if i change this to [1] atlas everything works fine. So what should we do now? checking whether user supplied LAPACKLIB="-lreflapack -lf77blas " works... no configure: error: user supplied LAPACK library "-lreflapack -lf77blas -lf77blas " The problem is probably that the line doesn't include -latlas. As far as I can see passing the values with --with-lapack-lib doesn't do what you think it does. If you do "ldd -r /usr/lib64/libCoinUtils.so.3.9.11" does it report reflapack? In fact the ebuild currently has: if use blas; then myeconfargs+=( --with-blas-lib="$($(tc-getPKG_CONFIG) --libs blas)" ) else myeconfargs+=( --without-blas ) fi which is probably what prompted the form of the patch but I am fairly sure that's wrong too. It is very to figure out because detection relies on macros not shipped with the coinor-utils tarball but the straight configure file logic seem to point out to that using --with-{blas,lapack}-lib=-lsomelibs won't do what you expect. # Check whether --with-blas or --without-blas was given. if test "${with_blas+set}" = set; then withval="$with_blas" use_blas="$withval" else use_blas= fi; # if user specified --with-blas-lib, then we should give COIN_CHECK_PACKAGE # preference # Check whether --with-blas-lib or --without-blas-lib was given. if test "${with_blas_lib+set}" = set; then withval="$with_blas_lib" use_blas=BUILD fi; And then so more complicated action. Similarly with lapack. Just using --with-{blas,lapack}-lib=-lsomelibs will not be catch by anything up there and will move to autodetection/building internal copy. (In reply to Francois Bissey from comment #6) [...] > The problem is probably that the line doesn't include -latlas. As far as I > can see passing the values with --with-lapack-lib doesn't do what you think > it does. If you do "ldd -r /usr/lib64/libCoinUtils.so.3.9.11" does it report > reflapack? # for i in lapack blas cblas ; do eselect $i list ; done Available providers for lapack: [1] atlas * [2] atlas-threads [3] reference Available providers for blas: [1] atlas * [2] atlas-threads [3] openblas-dynamic-int64-threads [4] reference Available providers for cblas: [1] atlas * [2] atlas-threads [3] gsl [4] openblas-dynamic-int64-threads [5] reference # ldd -r /usr/lib64/libCoinUtils.so.3.9.11 linux-vdso.so.1 (0x00007fff6a5ff000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fee51be1000) libz.so.1 => /lib64/libz.so.1 (0x00007fee519cb000) libglpk.so.0 => /usr/lib64/libglpk.so.0 (0x00007fee516fe000) libatllapack.so.3 => /usr/lib64/libatllapack.so.3 (0x00007fee50e10000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007fee50b08000) libm.so.6 => /lib64/libm.so.6 (0x00007fee5080d000) libc.so.6 => /lib64/libc.so.6 (0x00007fee50467000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fee50251000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007fee50046000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fee4fe42000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007fee4fbcc000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgfortran.so.3 (0x00007fee4f8b5000) libatlas.so.3 => /usr/lib64/libatlas.so.3 (0x00007fee4f1c9000) libatlcblas.so.3 => /usr/lib64/libatlcblas.so.3 (0x00007fee4efa4000) libf77blas.so.3 => /usr/lib64/libf77blas.so.3 (0x00007fee4ed80000) /lib64/ld-linux-x86-64.so.2 (0x00007fee52186000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libquadmath.so.0 (0x00007fee4eb4a000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fee4e92b000) I meant with your patch and lapack reference. Without your patch and atlas things probably configure properly. What would be really useful is /tmp/portage/sci-libs/coinor-utils-2.9.11/work/coinor-utils-2.9.11_build/config.log when you get the cinfiguration failure with lapack-reference. (In reply to Francois Bissey from comment #9) > I meant with your patch and lapack reference. Without your patch and atlas > things probably configure properly. # for i in lapack blas cblas ; do eselect $i list ; done Available providers for lapack: [1] atlas [2] atlas-threads [3] reference * Available providers for blas: [1] atlas * [2] atlas-threads [3] openblas-dynamic-int64-threads [4] reference Available providers for cblas: [1] atlas * [2] atlas-threads [3] gsl [4] openblas-dynamic-int64-threads [5] reference after compiling with my ebuild i get this: # ldd -r /usr/lib64/libCoinUtils.so.3.9.11 linux-vdso.so.1 (0x00007fff7edff000) libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f419f229000) libz.so.1 => /lib64/libz.so.1 (0x00007f419f013000) libglpk.so.0 => /usr/lib64/libglpk.so.0 (0x00007f419ed46000) libreflapack.so => /usr/lib64/libreflapack.so (0x00007f419e439000) libf77blas.so.3 => /usr/lib64/libf77blas.so.3 (0x00007f419e216000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libstdc++.so.6 (0x00007f419df0d000) libm.so.6 => /lib64/libm.so.6 (0x00007f419dc13000) libc.so.6 => /lib64/libc.so.6 (0x00007f419d86d000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f419d656000) libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f419d44c000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f419d248000) libgmp.so.10 => /usr/lib64/libgmp.so.10 (0x00007f419cfd1000) librefblas.so => /usr/lib64/librefblas.so (0x00007f419cd77000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgfortran.so.3 (0x00007f419ca61000) libatlas.so.3 => /usr/lib64/libatlas.so.3 (0x00007f419c374000) /lib64/ld-linux-x86-64.so.2 (0x00007f419f7ce000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libquadmath.so.0 (0x00007f419c13e000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f419bf1f000) undefined symbol: blas_zhemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_ssymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dsymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_csymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zsymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dsymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_csymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zhemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_ssymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zsymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_chemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_chemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgemv_x_ (/usr/lib64/libreflapack.so) > What would be really useful is > /tmp/portage/sci-libs/coinor-utils-2.9.11/work/coinor-utils-2.9.11_build/ > config.log when you get the cinfiguration failure with lapack-reference. i'll attach this soon. Created attachment 385346 [details]
config.log
config.log of the failed configure run
It looks like your reflapack is broken and while it seems to build with your patch it looks like the resulting coinor library is broken. The issue here is that your refblas wants symbols prefixed with blas, which is curious and I don't have anything like this here. So in the first instance rebuild lapack-reference and see if those symbols are still there. If they are still there we are really looking at a problem with lapack-reference on your machine. The problem with coinor-utils is just an external symptom. (In reply to Francois Bissey from comment #12) > It looks like your reflapack is broken and while it seems to build with your > patch it looks like the resulting coinor library is broken. ok, this i understand by now. > The issue here is that your refblas wants symbols prefixed with blas, which > is curious and I don't have anything like this here. me neither ;) > So in the first instance rebuild lapack-reference and see if those symbols > are still there. If they are still there we are really looking at a problem > with lapack-reference on your machine. The problem with coinor-utils is just > an external symptom. i rebuilded sci-libs/lapack-reference-3.5.0 (it's from "science" overlay) using these providers: # for i in lapack blas cblas ; do eselect $i list ; done Available providers for lapack: [1] atlas * [2] atlas-threads [3] reference Available providers for blas: [1] atlas * [2] atlas-threads [3] openblas-dynamic-int64-threads [4] reference Available providers for cblas: [1] atlas * [2] atlas-threads [3] gsl [4] openblas-dynamic-int64-threads [5] reference and this is the result: # strings -a /usr/lib64/libreflapack.so | grep 'blas_...mv' blas_sgemv2_x_ blas_sgemv_x_ blas_ssymv2_x_ blas_ssymv_x_ blas_sgbmv2_x_ blas_sgbmv_x_ blas_dgemv2_x_ blas_dgemv_x_ blas_dsymv2_x_ blas_dsymv_x_ blas_dgbmv2_x_ blas_dgbmv_x_ blas_cgemv2_x_ blas_cgemv_x_ blas_csymv2_x_ blas_csymv_x_ blas_chemv2_x_ blas_chemv_x_ blas_cgbmv2_x_ blas_cgbmv_x_ blas_zgemv2_x_ blas_zgemv_x_ blas_zsymv2_x_ blas_zsymv_x_ blas_zhemv2_x_ blas_zhemv_x_ blas_zgbmv2_x_ blas_zgbmv_x_ I most likely need the log of your lapack-reference build but I have a couple of ideas that may be diagnosed. I would like the output of readelf -d /usr/lib64/libreflapack.so and ldd -r /usr/lib64/libreflapack.so (In reply to Francois Bissey from comment #14) > I most likely need the log of your lapack-reference build but I have a > couple of ideas that may be diagnosed. I would like the output of let me check how i can keep the log, and i'll attach it later > readelf -d /usr/lib64/libreflapack.so # readelf -d /usr/lib64/libreflapack.so Dynamic section at offset 0x5fbdb8 contains 30 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libf77blas.so.3] 0x0000000000000001 (NEEDED) Shared library: [libgfortran.so.3] 0x0000000000000001 (NEEDED) Shared library: [libm.so.6] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libreflapack.so] 0x000000000000000c (INIT) 0x1fab0 0x000000000000000d (FINI) 0x5c78c8 0x0000000000000019 (INIT_ARRAY) 0x7fbda0 0x000000000000001b (INIT_ARRAYSZ) 8 (bytes) 0x000000000000001a (FINI_ARRAY) 0x7fbda8 0x000000000000001c (FINI_ARRAYSZ) 8 (bytes) 0x0000000000000004 (HASH) 0x1c8 0x000000006ffffef5 (GNU_HASH) 0x3018 0x0000000000000005 (STRTAB) 0x11b80 0x0000000000000006 (SYMTAB) 0x6378 0x000000000000000a (STRSZ) 16878 (bytes) 0x000000000000000b (SYMENT) 24 (bytes) 0x0000000000000003 (PLTGOT) 0x7fc000 0x0000000000000002 (PLTRELSZ) 35976 (bytes) 0x0000000000000014 (PLTREL) RELA 0x0000000000000017 (JMPREL) 0x16e28 0x0000000000000007 (RELA) 0x16d68 0x0000000000000008 (RELASZ) 192 (bytes) 0x0000000000000009 (RELAENT) 24 (bytes) 0x000000006ffffffe (VERNEED) 0x16cc8 0x000000006fffffff (VERNEEDNUM) 4 0x000000006ffffff0 (VERSYM) 0x15d6e 0x000000006ffffff9 (RELACOUNT) 3 0x0000000000000000 (NULL) 0x0 > ldd -r /usr/lib64/libreflapack.so # ldd -r /usr/lib64/libreflapack.so linux-vdso.so.1 (0x00007fff795ff000) libf77blas.so.3 => /usr/lib64/libf77blas.so.3 (0x00007fc9bc549000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgfortran.so.3 (0x00007fc9bc232000) libm.so.6 => /lib64/libm.so.6 (0x00007fc9bbf38000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc9bbd22000) libc.so.6 => /lib64/libc.so.6 (0x00007fc9bb97c000) libatlas.so.3 => /usr/lib64/libatlas.so.3 (0x00007fc9bb28f000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libquadmath.so.0 (0x00007fc9bb059000) /lib64/ld-linux-x86-64.so.2 (0x00007fc9bd0cf000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc9bae3a000) undefined symbol: blas_zhemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_ssymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dsymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_csymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zsymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dsymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_csymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zhemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_ssymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zsymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_chemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_chemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgemv_x_ (/usr/lib64/libreflapack.so) Hum... I was hoping for some clues but they are not there. The quickest way to generate a log in those circumstances would be to use the ebuild command directly as a normal user. ebuild /var/lib/layman/sci/sci-libs/lapack-reference/lapack-reference-3.5.0.ebuild install should do it without installing anything on the system. Once you got your log you can mop up by replacing install with clean. Created attachment 385428 [details]
build.log of sci-libs/lapack-reference-3.5.0
# for i in lapack blas cblas ; do eselect $i list ; done
Available providers for lapack:
[1] atlas *
[2] atlas-threads
[3] reference
Available providers for blas:
[1] atlas *
[2] atlas-threads
[3] openblas-dynamic-int64-threads
[4] reference
Available providers for cblas:
[1] atlas *
[2] atlas-threads
[3] gsl
[4] openblas-dynamic-int64-threads
[5] reference
OK, now I have a good idea what's happening. All those symbols belong to xblas. That's the _x at the end. But libreflapack is not properly linked to it. I.e. the final libreflapack.so library wasn't linked with -lxblas (or whatever it is supposed to be) so libreflapack doesn't know where to get those symbols. As far as I can see we should either make libreflapack link against libxblas or add it in the .pc file for reflapack, possibly in the require section since we install a xblas.pc A quick and dirty hack to the whole thing is probably to edit manually /usr/lib64/pkg_config/reflapack and change the last line from Requires: blas to Requires: blas xblas Technically I guess we should do both. Amend the .pc file and link. Ouch it is linked, but not in a "useful" way: -lf77blas /usr/lib64/libxblas.so Still have to augment the .pc file in any case. (In reply to Francois Bissey from comment #18) [...] > Technically I guess we should do both. Amend the .pc file and link. Ok, now i'm lost. Is there anything that i could/should do by now? I'll do if you just tell me what... ;) (In reply to Thomas Beutin from comment #20) > (In reply to Francois Bissey from comment #18) > [...] > > Technically I guess we should do both. Amend the .pc file and link. > > Ok, now i'm lost. Is there anything that i could/should do by now? > > I'll do if you just tell me what... ;) We need to fix the lapack-reference ebuild. I guess I could hack it tonight if no one beats me to it. I will just fix the .pc file. You can do it manually as I suggested if you are game. OK, got to it faster than I thought I could. Sync the science overlay, rebuild lapack-reference, eselect it and then try again. I am positive I fixed it but nothing beats an experimental fact. (In reply to Francois Bissey from comment #22) > OK, got to it faster than I thought I could. Sync the science overlay, > rebuild lapack-reference, eselect it and then try again. i synced, enabled =sci-libs/lapack-reference-9999, emerged it, and at the end i've still those unresolved symbols: # ldd -r /usr/lib64/libreflapack.so linux-vdso.so.1 (0x00007fffa0591000) libf77blas.so.3 => /usr/lib64/libf77blas.so.3 (0x00007f18d47a3000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgfortran.so.3 (0x00007f18d448c000) libm.so.6 => /lib64/libm.so.6 (0x00007f18d4192000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f18d3f7c000) libc.so.6 => /lib64/libc.so.6 (0x00007f18d3bd6000) libatlas.so.3 => /usr/lib64/libatlas.so.3 (0x00007f18d34e9000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libquadmath.so.0 (0x00007f18d32b3000) /lib64/ld-linux-x86-64.so.2 (0x00007f18d5329000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f18d3094000) undefined symbol: blas_zhemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_ssymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dsymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_csymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zsymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dsymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_csymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zhemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_sgbmv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_ssymv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zsymv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_chemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_chemv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_cgbmv_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_dgemv2_x_ (/usr/lib64/libreflapack.so) undefined symbol: blas_zgemv_x_ (/usr/lib64/libreflapack.so) Despite i (e)selected lapack-reference: # for i in lapack blas cblas ; do eselect $i list ; done Available providers for lapack: [1] atlas [2] atlas-threads [3] reference * Available providers for blas: [1] atlas * [2] atlas-threads [3] openblas-dynamic-int64-threads [4] reference Available providers for cblas: [1] atlas * [2] atlas-threads [3] gsl [4] openblas-dynamic-int64-threads [5] reference But the build of sci-libs/coinor-utils-2.9.11 failed for the same reason: [...] checking for COIN-OR package Blas... yes checking whether user supplied LAPACKLIB="-lreflapack -lf77blas -lxblas " works... no configure: error: user supplied LAPACK library "-lreflapack -lf77blas -lxblas -lf77blas " does not work !!! Please attach the following file when seeking support: !!! /tmp/portage/sci-libs/coinor-utils-2.9.11/work/coinor-utils-2.9.11_build/config.log I'll attach the build.log Created attachment 385436 [details]
config.log of sci-libs/coinor-utils-2.9.11 after merging sci-libs/lapack-reference-9999
it's the config log instead of the build.log
That's quite annoying. Output of nm -D /usr/lib64/libxblas.so | grep blas_ I will have to sleep on it until morning. (In reply to Francois Bissey from comment #25) > That's quite annoying. Output of > nm -D /usr/lib64/libxblas.so | grep blas_ # nm -D /usr/lib64/libxblas.so | grep blas_ 00000000000099c0 T blas_free 00000000000099b0 T blas_malloc 00000000000099e0 T blas_realloc > I will have to sleep on it until morning. Good night! :) Well I did a basic install of xblas and I have a lot more blas_* symbol, I certainly have a truckload of cblas_*_x_ ones. Perhaps you have an old instal of xblas? But actually there is another bug in lapack-reference I am sure, the dependency should be on xblas[fortran]. Have you built xblas with the fortran use flag? One quick check later and it looks like this is exactly the problem. Without the fortran flag you get c symbols in BLAS_*_x but none in blas_*_x_ which are all fortran ones. Fixing... OK pushed. Now rebuilding lapack-reference[xblas] will ask you to rebuild xblas[fortran] be sure to update your useflags. (In reply to Francois Bissey from comment #28) > OK pushed. Now rebuilding lapack-reference[xblas] will ask you to rebuild > xblas[fortran] be sure to update your useflags. that seems to solve the issue: # ldd -r /usr/lib64/libreflapack.so linux-vdso.so.1 (0x00007fffb69e8000) libf77blas.so.3 => /usr/lib64/libf77blas.so.3 (0x00007f3a10687000) libxblas.so.1.0 => /usr/lib64/libxblas.so.1.0 (0x00007f3a100d9000) libgfortran.so.3 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libgfortran.so.3 (0x00007f3a0fdc2000) libm.so.6 => /lib64/libm.so.6 (0x00007f3a0fac8000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3a0f8b2000) libc.so.6 => /lib64/libc.so.6 (0x00007f3a0f50b000) libatlas.so.3 => /usr/lib64/libatlas.so.3 (0x00007f3a0ee1f000) libquadmath.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/libquadmath.so.0 (0x00007f3a0ebe9000) /lib64/ld-linux-x86-64.so.2 (0x00007f3a1120d000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3a0e9ca000) and sci-libs/coinor-utils-2.9.11 compiled fine. |