Bugzilla Bug 230837

* 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.