Date: Mon, 16 Oct 2017 11:39:54 +0200 From: Tijl Coosemans <tijl@FreeBSD.org> To: Gleb Popov <6yearold@gmail.com> Cc: FreeBSD ports list <freebsd-ports@freebsd.org> Subject: Re: Using blaslapack Message-ID: <20171016113954.4a5bb6dd@kalimero.tijl.coosemans.org> In-Reply-To: <CALH631=mEn2p2cmE7t7cWsoDpJceEjFgd_sE2eMe3QRUqx=iDA@mail.gmail.com> References: <CALH631nHU9ZSkJKx4ptgcRTDASmi7UnMnjPGHWtaWEEK_Y-8hw@mail.gmail.com> <CALH631kiVycknq8NNEu-CemJkEZoTzchgFQoqyk7d88Q2Bjsmg@mail.gmail.com> <CALH631nWkhedW5s=8R-GWZnZ3fsYM4hVN=yXXMe2QFo8vc4KDw@mail.gmail.com> <CALH631k2kAs0qtz36XvY=c2xcsrgetriA_iNqQMhavxTtES1=g@mail.gmail.com> <CALH631=YD2qoTNDh6r%2B0%2Bb-OzADEC-8F9HAQ4uoOWZuPw44zjA@mail.gmail.com> <CALH631mDpr2VFoVnxB5oegkL5UdNmRvmv7i_ZNMfQLLHB=KbUQ@mail.gmail.com> <CALH631=VdJd78ixjGJg1=N=LphTyiBbpk2GAnR34m42EUzdy1Q@mail.gmail.com> <CALH631=NSpx76EVVHWMBtGAKTWzD_nfU5EPUH5EwOkPXaBVRAA@mail.gmail.com> <CALH631kvLSZpRmcVg_zrXTq105zs97LdUvqgXh6QPv64x=U-Tg@mail.gmail.com> <CALH631kYp-7HcGwoeTtzrF%2BZhW4b8c6O-GpCQMLj2JuyWBLUfA@mail.gmail.com> <CALH631=0aW8Ag_khWBUyDE=3kJoHt9zC75YXkqiFXxiHrzo8cA@mail.gmail.com> <CALH631nw1pqoDewgHpm_SQYWa490WiGdYdhqo3tNfiHK_uiPCw@mail.gmail.com> <CALH631=c%2BoSuS6=J7G3r8njAmVBQG_oeBb=7EtEZvoO2t=c=zA@mail.gmail.com> <CALH631=mEn2p2cmE7t7cWsoDpJceEjFgd_sE2eMe3QRUqx=iDA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Oct 2017 09:20:26 +0300 Gleb Popov <6yearold@gmail.com> wrote: > I'm porting an application (DLib, https://reviews.freebsd.org/D12559) that > uses BLAS and LAPACK, and I have some questions. > > 1. Is there any pure C implementation that does not require Fortran > compiler? Probably not, BLAS and LAPACK are Fortran libraries. Any implementation in C still provides Fortran wrappers. And often these implementations only implement performance critical functions and use the original Fortran for everything else. > 2. My application looks for cblas_ddot function in BLAS library, but the > default library (netlib) doesn't seem to have that. It has ddot, though, so > I'm not sure if it is a wrong check on app's side, or netlib is indeed > doesn't suit there. For now I've used openblas, but I'm also not sure if it > is a right choice. It's part of CBLAS which is also included in OpenBLAS. > 3. How to link properly to any of BLAS libraries? All BLAS implementations > blaslapack.mk features require Fortran. This implies USE_GCC=yes, so these > are compiled with GCC, not Clang. Now when I try to link Clang-compiled > DLib to GCC-compiled openblas, I get undefined references: > > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__getf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__floatunditf@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__subtf3@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__multf3@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__unordtf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__lttf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__addtf3@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__gttf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__divtf3@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__letf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__netf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__floatditf@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__eqtf2@GCC_4.6.0' > //usr/local/lib/gcc6/libgfortran.so.3: undefined reference to > `__floatsitf@GCC_4.6.0' > > I've tracked these symbols to /usr/local/lib/gcc6/libgcc_s.so. But there is > also /usr/lib/libgcc_s.so and it doesn't have such symbols. I suspect this > is the source of the error, but I wasn't able to fix it. Passing -Wl,-rpath > as advised by lang/gcc6 pkg-message doesn't help. The only workaround I > came up with is USE_GCC=yes to compile DLib itself, but that's pretty > unsatisfactory. This is a known problem. If your port depends on another port that has USES=fortran the easiest is to add USES=fortran to your port as well. C code will still be built with Clang then.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171016113954.4a5bb6dd>