Hi. The recent bump of numeric fails on amd64 with: ... ... building '_dotblas' extension creating build/temp.linux-x86_64-2.4/Packages/dotblas creating build/temp.linux-x86_64-2.4/Packages/dotblas/dotblas x86_64-pc-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -march=athlon64 -msse3 -O2 -pipe -fPIC -DCBLAS_HEADER=<cblas.h> -I/usr/include/atlas -IInclude -IPackages/FFT/Include -IPackages/RNG/Include -I/usr/include/python2.4 -c Packages/dotblas/dotblas/_dotblas.c -o build/temp.linux-x86_64-2.4/Packages/dotblas/dotblas/_dotblas.o x86_64-pc-linux-gnu-gcc -pthread -shared -march=athlon64 -msse3 -O2 -pipe build/temp.linux-x86_64-2.4/Packages/dotblas/dotblas/_dotblas.o -lcblas -lblas -latlas -lg2c -o build/lib.linux-x86_64-2.4/_dotblas.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lg2c collect2: ld returned 1 exit status error: command 'x86_64-pc-linux-gnu-gcc' failed with exit status 1 Complete log as well as emerge --info are given as attachments.
Created attachment 129813 [details] build.log
Created attachment 129815 [details] emerge --info
Created attachment 129817 [details] patch log
patch.log is from a patch error with a patch only for python-2.5 while this bug has no patch error and is with python-2.4....somehow unrelated?
As you can probably see, this bug contains comments from two different persons. My comments (opening, emerge --info and build.log) are with 2.4, as you can also probably see from the attached emerge --info.
Comment on attachment 129817 [details] patch log Unrelated and already fixed.
Created attachment 129821 [details] numeric-24.2-python25.patch-29255.out * Failed Patch: numeric-24.2-python25.patch ! * ( /usr/portage/dev-python/numeric/files/numeric-24.2-python25.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/dev-python/numeric-24.2-r6/temp/numeric-24.2-python25.patch-29255.out
Peter, see bug 191022
I'm having the same bug, also on amd64. I googled around and apparently that library is related to libf2c. I emerged emerging dev-libs/libf2c. Then I did emerge numeric, froze it when it says ">>> Source unpacked.", replaced all four occurrences of g2c with f2c in Numeric-24.2/customize.py, and resumed the build. It built fine, but I'm not quite sure it'll -function- properly; I have no idea what g2c/f2c does or what the difference is. But at least it finished the build.
Found this googling around: "These libraries normally referred to collectively as libf2c. When built as part of g77, libf2c is installed under the name libg2c to avoid conflict with any existing version of libf2c, and thus is often referred to as libg2c when the g77 version is specifically being referred to." So apparently these are the same. I suppose all that's needed is a small patch to substitute the names, then, or perhaps something that checks under which name, if any, the library is installed, or somesuch.
Hi. These libraries contain wrappers to use Fortran to C converters. (Small note: although not being sure if this is related at all, the issue might be a little more complicated than just substituting the names; e.g. the discussion, not the conclusions, in the closed bug #186913, i.e. is there a Fortran interface also in Numeric and not only in Numpy?)
This bug should have been fixed over the last commits. Could you resync your tree and emerge numeric-24.2-r6 again? If you still see the problem, please mention your blas-atlas or cblas-reference versions. Numeric does not have a fortran wrapper. Numpy has integrated f2py into their tree. For info, libg2c comes with g77 (gcc-3.*), the new lib with gcc-4 is libgfortran.
Hi. Resynced and the same problem still occurs with numeric-24.2-r6, but with your help I was able to locate the problem. The system has the recent blas-atlas that has worked fine in other instances, [ebuild R ] sci-libs/blas-atlas-3.7.34 USE="-debug -doc" 0 kB¨ with Installed BLAS for library directory lib64 [1] atlas [2] threaded-atlas * Installed CBLAS for library directory lib64 [1] atlas [2] threaded-atlas * I also tried to reselect the blas/cblas profiles (for which I had to follow the issues mentioned in the bug #189942), but this did not change anything. Yet, when I set, with the same blas-atlas-3.7.34, the profiles to: Installed CBLAS for library directory lib64 [1] atlas * [2] threaded-atlas zealot misc # eselect blas list Installed BLAS for library directory lib64 [1] atlas * [2] threaded-atlas and recompile numeric-24.6-r6, it compiles fine with no errors whatsoever. I can reproduce the error by setting the references back to threaded-atlas. Thus, it must be in the ebuild itself; and indeed I get a clean emerge by rewriting, for instance, elif [[ "${mycblas}" == threaded-atlas ]]; then', on the line 78 of numeric-24.2-r6.ebuild.
> I can reproduce the error by setting the references back to threaded-atlas. > Thus, it must be in the ebuild itself; and indeed I get a clean emerge by > rewriting, for instance, elif [[ "${mycblas}" == threaded-atlas ]]; then', on > the line 78 of numeric-24.2-r6.ebuild. I just cleaned-up and updated a bit the lapack/fortran bit. It passed all tests with all allowed cblas/lapack libs, threaded or not. Let me know if it is the same for you next time you re-sync.
Sebastien, problem solved: works fine now with threaded-atlas. Thank you, and closing this one.
