* camfr-20070717.tgz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking camfr-20070717.tgz ;-) ... [ ok ] * You need one of these Fortran Compilers: gfortran g77 ifc * Installed are: gfortran >>> Unpacking source... >>> Unpacking camfr-20070717.tgz to /var/tmp/portage/sci-physics/camfr-20070717/work * Applying camfr-20070717-gcc43.patch ... [ ok ] >>> Source unpacked. >>> Compiling source in /var/tmp/portage/sci-physics/camfr-20070717/work/camfr_20070717 ... Traceback (most recent call last): File "setup.py", line 8, in ? from machine_cfg import * File "/var/tmp/portage/sci-physics/camfr-20070717/work/camfr_20070717/machine_cfg.py", line 79 library_dirs = [, "/opt/intel/mkl/10.0.3.020/lib/32"] ^ SyntaxError: invalid syntax * * ERROR: sci-physics/camfr-20070717 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 3011: Called distutils_src_compile * environment, line 874: Called die * The specific snippet of code: * ${python} setup.py build "$@" || die "compilation failed" * The die message: * compilation failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/sci-physics/camfr-20070717/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sci-physics/camfr-20070717/temp/environment'. * Reproducible: Always
fixed again!
Thanks, we are getting there. But now I get: python Python 2.4.4 (#1, May 30 2008, 07:12:18) [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from camfr import * Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/lib/python2.4/site-packages/PIL/__init__.py", line 8, in ? # ImportError: /opt/intel/mkl/10.0.3.020/lib/32/libmkl_gnu_thread.so: undefined symbol: _gfortran_malloc >>>
Hi Peter, I fixed a few errors in the mkl pkg-config files, and added the fortran lib to link in camfr. I eselected mkl profiles for all, recompiled numpy, scipy and camfr, but I get the MKL_FATAL_ERROR in importing camfr. mkl-10.0.2.108-r1 (which I fixed too) seems to behave a bit better. I hope things work for you, I never use camfr! NB: While looking at the camfr package sources, I noticed the machine_cfg.py.gentoo could really be more portable by using the toolchain environment variables instead of sourcing /etc/make.conf and forcing GNU compilers.
Sorry to keep pestering you. I downgraded mkl. Compiling now works, as does importing, but running the test suite I get: python camfr_test.py CAMFR 20070717 - Copyright (C) 1998-2007 Peter Bienstman - Ghent University. Running blazed grating... MKL FATAL ERROR: /opt/intel/mkl/10.0.2.018/lib/em64t/libmkl_lapack.so: undefined symbol: __mkl_cfg_file_readed_extern
Hi, Could you try two more things: * add -lmkl_lapack in the Libs part of the /opt/intel/mkl/1*/lib/*/lapack*pc, just after -lmkl_core, and re-install numpy, scipy and camfr * if your are using gcc-4.1.2 and a threaded blas/lapack mkl gfortran profile, install and test with with gcc-4.2.4 or gcc-4.3.1. Thanks,
Adding -lmkl_lapack gives python camfr_test.py CAMFR 20070717 - Copyright (C) 1998-2007 Peter Bienstman - Ghent University. Running blazed grating... MKL FATAL ERROR: /opt/intel/mkl/10.0.3.020/lib/32/: cannot read file data: Is a directory Does it still make sense to upgrade gcc? If so, with our without the mkl_lapack change?
> MKL FATAL ERROR: /opt/intel/mkl/10.0.2.018/lib/em64t/libmkl_lapack.so: > MKL FATAL ERROR: /opt/intel/mkl/10.0.3.020/lib/32/: cannot read file data: Is Which version of mkl are you using? 10.0.2.018 should be more stable with respect to numpy/scipy. amd64 or x86? > Does it still make sense to upgrade gcc? If so, with our without the >mkl_lapack change? gcc upgrade probably makes sense if you use the mkl-gfortran-threads eselect profile. I think the mkl_gnu_thread library uses gfortran > 4.2, but I'm not sure about that. Also only libgfortran >= 4.3 is really version independent. And test with the mkl_lapack change.
Upgrading gcc to 4.3, using MKL 10.0.2.018, together with the mkl lapack change finally made things work, both on amd64 and x86. (I did have to recompile blitz and upgrade boost to a ~arch version because of gcc 4.3 issues, though.) Thanks a lot for tracking this down!
(In reply to comment #8) > Upgrading gcc to 4.3, using MKL 10.0.2.018, together with the mkl lapack change > finally made things work, both on amd64 and x86. If you still have the gcc-4.1.2 profile around, could you tell me if it works also for mkl gcc-4.1.2? I would need to update mkl deps. Thanks
I couldn't get it to work with 4.1...
I added mkl_lapack in lapack mkl profiles and added a warning for gcc <4.2 users using the gfortran-threads profile. It should close this bug then. Thanks.
