sklearn/linear_model/cd_fast.c:18729:27: error: type of formal parameter 1 is incomplete __pyx_v_ger(CblasRowMajor, __pyx_v_n_samples, __pyx_v_n_tasks, 1.0, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, __pyx_v_wii_ptr, 1, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_31 * __pyx_v_R.strides[0]) )) + __pyx_t_32)) )))), __pyx_v_n_tasks); ^~~~~~~~~~~~~ sklearn/linear_model/cd_fast.c:18766:26: error: type of formal parameter 1 is incomplete __pyx_v_gemv(CblasRowMajor, CblasTrans, __pyx_v_n_samples, __pyx_v_n_tasks, 1.0, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_33 * __pyx_v_R.strides[0]) )) + __pyx_t_34)) )))), __pyx_v_n_tasks, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, 0.0, (&(*((double *) ( /* dim=0 */ ((char *) (((double *) __pyx_v_tmp.data) + __pyx_t_35)) )))), 1); ^~~~~~~~~~~~~ sklearn/linear_model/cd_fast.c:18766:41: error: type of formal parameter 2 is incomplete __pyx_v_gemv(CblasRowMajor, CblasTrans, __pyx_v_n_samples, __pyx_v_n_tasks, 1.0, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_33 * __pyx_v_R.strides[0]) )) + __pyx_t_34)) )))), __pyx_v_n_tasks, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, 0.0, (&(*((double *) ( /* dim=0 */ ((char *) (((double *) __pyx_v_tmp.data) + __pyx_t_35)) )))), 1); ^~~~~~~~~~ sklearn/linear_model/cd_fast.c:18833:27: error: type of formal parameter 1 is incomplete __pyx_v_ger(CblasRowMajor, __pyx_v_n_samples, __pyx_v_n_tasks, -1.0, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, (__pyx_v_W_ptr + (__pyx_v_ii * __pyx_v_n_tasks)), 1, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_39 * __pyx_v_R.strides[0]) )) + __pyx_t_40)) )))), __pyx_v_n_tasks); ^~~~~~~~~~~~~ error: Command "x86_64-pc-linux-gnu-gcc -mtune=core2 -march=core2 -O2 -msse4.1 -pipe -ffat-lto-objects -fPIC -fstack-protector-strong -fPIC -DNO_ATLAS_INFO=1 -DHAVE_CBLAS -I../src/cblas -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/refcblas -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c sklearn/linear_model/cd_fast.c -o /var/tmp/portage/sci-libs/scikits_learn-0.19.0/work/scikit-learn-0.19.0-python2_7/temp.linux-x86_64-2.7/sklearn/linear_model/cd_fast.o -MMD -MF /var/tmp/portage/sci-libs/scikits_learn-0.19.0/work/scikit-learn-0.19.0-python2_7/temp.linux-x86_64-2.7/sklearn/linear_model/cd_fast.o.d" failed with exit status 1 * ERROR: sci-libs/scikits_learn-0.19.0::gentoo failed (compile phase): Reproducible: Always Steps to Reproduce: 1.emerge -va scikits_learn 2. 3. Actual Results: failed Expected Results: installed
Created attachment 493182 [details] emerge.info emerge --info '=sci-libs/scikits_learn-0.19.0::gentoo'> emerge.info
Created attachment 493184 [details] emerge.pqv emerge -pqv '=sci-libs/scikits_learn-0.19.0::gentoo'>emerge.pqv
Created attachment 493186 [details] build.log
Created attachment 493188 [details] environment
(1)this bug is related to: Bug 543560 - =sci-libs/scikits_learn-0.15.2 needs cblas beeing set (cblas alternatives are not set after emerge) (2)a workaround: <1>emerge sci-libs/gsl <2>make sure gsl is selected in 'eselect cblas' ---------------- eselect cblas list Installed CBLAS for library directory lib64 [1] gsl * [2] reference ---------------- eselect cblas set 1 ---------------- <3>emerge sci-libs/scikits (3)sci-libs/gsl/gsl-2.4.ebuild does not set gsl in "eselect cblas" caused this bug, IIUC
Created attachment 514562 [details] emerge --info
Created attachment 514564 [details] emerge -pqv
Created attachment 514566 [details] build.log
Created attachment 514568 [details] environment
sklearn/linear_model/cd_fast.c:18729:27: error: type of formal parameter 1 is incomplete __pyx_v_ger(CblasRowMajor, __pyx_v_n_samples, __pyx_v_n_tasks, 1.0, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, __pyx_v_wii_ptr, 1, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_31 * __pyx_v_R.strides[0]) )) + __pyx_t_32)) )))), __pyx_v_n_tasks); ^~~~~~~~~~~~~ sklearn/linear_model/cd_fast.c:18766:26: error: type of formal parameter 1 is incomplete __pyx_v_gemv(CblasRowMajor, CblasTrans, __pyx_v_n_samples, __pyx_v_n_tasks, 1.0, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_33 * __pyx_v_R.strides[0]) )) + __pyx_t_34)) )))), __pyx_v_n_tasks, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, 0.0, (&(*((double *) ( /* dim=0 */ ((char *) (((double *) __pyx_v_tmp.data) + __pyx_t_35)) )))), 1); ^~~~~~~~~~~~~ sklearn/linear_model/cd_fast.c:18766:41: error: type of formal parameter 2 is incomplete __pyx_v_gemv(CblasRowMajor, CblasTrans, __pyx_v_n_samples, __pyx_v_n_tasks, 1.0, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_33 * __pyx_v_R.strides[0]) )) + __pyx_t_34)) )))), __pyx_v_n_tasks, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, 0.0, (&(*((double *) ( /* dim=0 */ ((char *) (((double *) __pyx_v_tmp.data) + __pyx_t_35)) )))), 1); ^~~~~~~~~~ sklearn/linear_model/cd_fast.c:18833:27: error: type of formal parameter 1 is incomplete __pyx_v_ger(CblasRowMajor, __pyx_v_n_samples, __pyx_v_n_tasks, -1.0, (__pyx_v_X_ptr + (__pyx_v_ii * __pyx_v_n_samples)), 1, (__pyx_v_W_ptr + (__pyx_v_ii * __pyx_v_n_tasks)), 1, (&(*((double *) ( /* dim=1 */ ((char *) (((double *) ( /* dim=0 */ (__pyx_v_R.data + __pyx_t_39 * __pyx_v_R.strides[0]) )) + __pyx_t_40)) )))), __pyx_v_n_tasks); ^~~~~~~~~~~~~ error: Command "x86_64-pc-linux-gnu-gcc -mtune=core2 -march=core2 -O2 -msse4.1 -pipe -ffat-lto-objects -fPIC -fstack-protector-strong -fPIC -DNO_ATLAS_INFO=1 -DHAVE_CBLAS -I../src/cblas -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/refcblas -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c sklearn/linear_model/cd_fast.c -o /var/tmp/portage/sci-libs/scikits_learn-0.19.0/work/scikit-learn-0.19.0-python2_7/temp.linux-x86_64-2.7/sklearn/linear_model/cd_fast.o -MMD -MF /var/tmp/portage/sci-libs/scikits_learn-0.19.0/work/scikit-learn-0.19.0-python2_7/temp.linux-x86_64-2.7/sklearn/linear_model/cd_fast.o.d" failed with exit status 1 * ERROR: sci-libs/scikits_learn-0.19.0::gentoo failed (compile phase):
same error while gsl is selected # eselect cblas list Available providers for cblas: [1] gsl * [2] reference
(In reply to tastu teche from comment #5) > (1)this bug is related to: > Bug 543560 - =sci-libs/scikits_learn-0.15.2 needs cblas beeing set (cblas > alternatives are not set after emerge) > > (2)a workaround: > <1>emerge sci-libs/gsl > <2>make sure gsl is selected in 'eselect cblas' > ---------------- > eselect cblas list > Installed CBLAS for library directory lib64 > [1] gsl * > [2] reference > ---------------- > eselect cblas set 1 > ---------------- > <3>emerge sci-libs/scikits > > > (3)sci-libs/gsl/gsl-2.4.ebuild does not set gsl in "eselect cblas" caused > this bug, IIUC emerge and select gsl is of no use.
At least in the original log cblas reference is selected. It is also possible that you get the version of cblas numpy was compiled with. numpy keeps a record of the cblas/lapack it was installed with. It appears scikits uses numpy for a lot of things and your cblas could very well be inherited even when selecting gsl. I put that in the column "to check". You should be able to figure out from lines at the beginning of the build log FOUND: libraries = ['refblas', 'refcblas'] library_dirs = ['/usr/lib64'] language = c define_macros = [('HAVE_CBLAS', None)] include_dirs = ['/usr/include/refcblas'] FOUND: libraries = ['refblas', 'refcblas'] library_dirs = ['/usr/lib64'] define_macros = [('NO_ATLAS_INFO', 1), ('HAVE_CBLAS', None)] language = c include_dirs = ['/usr/include/refcblas'] Otherwise I am not convinced yet the cblas selected is the source of the problem.
(In reply to François Bissey from comment #13) the previous numpy and scipy packages were not compiled with gsl selected. the problem is resolved by emerge numpy and scipy again after select gsl, and then emerge scikits_learn.
(In reply to François Bissey from comment #13) thank you very much!
I am getting the same issue (on multiple systems). Does this mean that ?=scikits_learn-0.19.0 is broken unless you have cblas gls selected?
> I am getting the same issue (on multiple systems). Does this mean that ?=scikits_learn-0.19.0 is broken unless you have cblas gls selected? scikit-learn vendors CBLAS and in Gentoo it is removed in favour of the system one (https://github.com/gentoo/gentoo/blob/dbd129895852cbeabe59b156a29f1f1d6d0eea2c/sci-libs/scikits_learn/scikits_learn-0.19.0.ebuild#L58), this may be causing these issues.
I can confirm this on new install with only cblas-reference (eselected), numpy 1.14.5, scipy 1.1.0, scikits 0.19.0.
Created attachment 547856 [details] build.log
I have the same issue with updated scikits_learn-0.19.0-r1 ebuild using the new blas/lapack settings. Because gsl isn't eselect-ldso aware, there's no way of selecting it as a blas/cblas provider. I'm currently having openblas set for both blas/cblas and lapack providers. artus /etc # eselect blas list Available BLAS/CBLAS (lib) candidates: (none found) Available BLAS/CBLAS (lib64) candidates: [1] openblas * [2] reference artus /etc # eselect lapack list Available LAPACK (lib) candidates: (none found) Available LAPACK (lib64) candidates: [1] openblas * [2] reference I had gsl installed without cblas-external USE flag set first and had the same issue. After this, I tried re-emering gsl with USE=cblas-external, rebuilt numpy and scipy but still the same. The libraries it finds are as follows: FOUND: libraries = ['blas', 'cblas'] library_dirs = ['/usr/lib64'] include_dirs = ['', '/usr/include'] language = c define_macros = [('HAVE_CBLAS', None)] FOUND: define_macros = [('NO_ATLAS_INFO', 1), ('HAVE_CBLAS', None)] libraries = ['blas', 'cblas'] library_dirs = ['/usr/lib64'] include_dirs = ['', '/usr/include'] language = c What I find suspect, is that it doesn't seem to find my installed atlas-3.10.2 package, if I interpret the output correctly.
Created attachment 585656 [details] scikits_learn-0.19.0-r1:20190804-110908.log build log
Created attachment 585748 [details] build log I'm seeing the same problem as Bernd. # eselect blas list Available BLAS/CBLAS (lib) candidates: (none found) Available BLAS/CBLAS (lib64) candidates: [1] blis [2] openblas * [3] reference # eselect lapack list Available LAPACK (lib) candidates: (none found) Available LAPACK (lib64) candidates: [1] openblas * [2] reference
OK, it seems I've figured it out. Here is description of what happens (duplicated from scikit-learn bugzilla): The cause of this problem is incorrect CBLAS API of internal scikit-learn CBLAS library used in 0.20 (and probably since ever). The two enum's, `CBLAS_ORDER` and `CBLAS_TRANSPOSE` (and all others also, but they don't cause build errors) declared there without `typedef` keyword, which is required by CBLAS API (e.g. OpenBLAS: https://github.com/xianyi/OpenBLAS/blob/develop/cblas.h#L49, reference LAPACK: https://github.com/xianyi/OpenBLAS/blob/develop/lapack-netlib/CBLAS/include/cblas.h#L19). This leads to incorrect C source generation by Cython, and when this source is building against correct CBLAS implementation we've got that we've got. So, the real fix should be declaring all enums in `scikit-learn`s' CBLAS implementation with `typedef`s and regenerating C sources for *.pyx. But for now I propose simple patch that will fix incorrectly generated C source code. Written & tried it on 0.20.3, but should work on 0.19 also. Beware that I've also migrated to the new blas/lapack settings, so your experience may vary.
Created attachment 586280 [details, diff] Fix sklearn/linear_model/cd_fast.c build error
(In reply to Alex from comment #24) > Created attachment 586280 [details, diff] [details, diff] > Fix sklearn/linear_model/cd_fast.c build error Thanks Alex... I wasn't able to use the patch directly w/ 0.19-r1; however, I took the concept of removing "enum" from in front of CBLAS_ORDER and CBLAS_TRANSPOSE, and generated my own patch which allowed me to build 0.19-r1. (Note: I have not done any sort of runtime testing.) If somebody wants my version of the patch I'm happy to share; however, I'm rather skeptical that it will `just work' for anyone else -- probably best to just create your own. -Max.
Created attachment 596282 [details, diff] scikits_learn patch for 0.19 The comment from Alex #24 gave me the idea of creating this patch. He did it for the 0.20 version, which is not available here yet, so I adapted it to the 0.19.x. Tried here and working.
jorgicio's patch https://bugs.gentoo.org/attachment.cgi?id=596282 worked for me.
I'm affected by this with 0.19.0-r1 , and the patch does fix the problem. Mind adding it to portage tree?
(In reply to Andrew from comment #28) > I'm affected by this with 0.19.0-r1 , and the patch does fix the problem. > Mind adding it to portage tree? It seems that Gentoo dev team is so underhanded that they couldn't even review PR's from contributors, much less do something on their own. I advise you to create your own local repo to put custom ebuilds there. I already have about ~140 of must-have-but-cant-make-their-way-to-main-repo packages in my own...
(In reply to Alex from comment #29) > > It seems that Gentoo dev team is so underhanded […]. I think you mean understaffed: https://www.merriam-webster.com/dictionary/underhanded > I advise you to create your own local repo to put custom ebuilds there. It is always useful to have a local repo. But for this package, I would advise to just put the patch in /etc/portage/patches/sci-libs/scikits_learn-0.19.0-r1 and re-emerge.
(In reply to Erik Quaeghebeur from comment #30) > I think you mean understaffed: > https://www.merriam-webster.com/dictionary/underhanded Wow, thank you very much! I honestly tough that "to be underhanded" meant "to not have enough hands". My English is still not best. > It is always useful to have a local repo. But for this package, I would > advise to just put the patch in > > /etc/portage/patches/sci-libs/scikits_learn-0.19.0-r1 > > and re-emerge. Probably it's wise to also bump package version to latest 0.20, as it builds and works fine (at least for me for couple of months), and 0.20 won't make it's way into the main tree until the heat death of the Universe...
(In reply to Alex from comment #31) > Wow, thank you very much! I honestly tough that "to be underhanded" meant > "to not have enough hands". My English is still not best. * thought (That's just mistype, not my English =) )
Fixed in a1444fbbd220ed8e8357631a0d9d333551fea43b (bumped to 0.20, couldn't figure out how to fix 0.19)
Thanks Patrick, the 0.20 works.
