230837 2008-07-05 10:42 0000 sci-physics/camfr-20070717/ does not compile 2008-07-13 18:59:39 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED FIXED P2 normal --- 1 Peter.Bienstman@UGent.be sci-physics@gentoo.org Peter.Bienstman@UGent.be 2008-07-05 10:42:13 0000 * 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 bicatali@gentoo.org 2008-07-06 10:25:47 0000 fixed again! Peter.Bienstman@UGent.be 2008-07-06 15:55:31 0000 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 >>> bicatali@gentoo.org 2008-07-08 09:19:59 0000 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. Peter.Bienstman@UGent.be 2008-07-08 09:44:20 0000 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 bicatali@gentoo.org 2008-07-09 15:58:50 0000 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, Peter.Bienstman@UGent.be 2008-07-10 06:09:13 0000 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? bicatali@gentoo.org 2008-07-10 09:23:53 0000 > 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. Peter.Bienstman@UGent.be 2008-07-10 18:56:26 0000 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! bicatali@gentoo.org 2008-07-11 08:22:54 0000 (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 Peter.Bienstman@UGent.be 2008-07-11 10:42:34 0000 I couldn't get it to work with 4.1... bicatali@gentoo.org 2008-07-13 18:59:39 0000 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.