Unable to compile deal.II with Intel Compiler 2013

[Ted Kord]

Has anyone successfully compiled deal.II with the latest Intel C++ compiler? Using the following configure line:

./configure --enable-shared --enable-threads --enable-multithreading --with-multithreading --with-umfpack --with-blas="mkl_intel_lp64 -Wl,--start-group -lmkl_intel_thread -lmkl_core -Wl,--end-group -lguide -lpthread" LDFLAGS="-L/opt/intel/mkl/lib/intel64" LD_LIBRARY_PATH=/opt/intel/mkl/lib/intel64:/opt/intel/lib/intel64:$LD_LIBRARY_PATH

I get the following error:

checking for daxpy_... no
configure: error: BLAS library not installed correctly(mkl_intel_lp64 -Wl,--start-group -lmkl_intel_thread -lmkl_core -Wl,--end-group -lguide -lpthread)

==
TK

[Ted Kord]

I've tried to follow a thread where Praveen had similar problems with the 2011 version but I still get the same error. I'm using intel composer 2013 with the following configure line:

./configure --enable-shared --disable-mpi --enable-threads --enable-multithreading --with-multithreading --with-umfpack --with-blas="mkl_intel_lp64 -Wl,--start-group -lmkl_intel_thread -lmkl_core -Wl,--end-group -lguide -lpthread" LDFLAGS=-L/opt/intel/composerxe/mkl/lib/intel64

The error is:

checking for daxpy_... no
configure: error: BLAS library not installed correctly(mkl_intel_lp64 -Wl,--start-group -lmkl_intel_thread -lmkl_core -Wl,--end-group -lguide -lpthread)

What am I doing incorrectly?

TK.

[Timo Heister]

Hi Ted,

can you take a look at the error that is written to config.log regarding that failing configure check?

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
 
 

--
Timo Heister
http://www.math.tamu.edu/~heister/

[Ted Kord]

Hi Timo

The error in config.log points to line 13243 (below) in config.log. I can't see a problem though:

13238 if test "x$with_blas" != "x" -a "x$with_blas" != "xno" ; then
13239   ac_fn_cxx_check_func "$LINENO" "daxpy_" "ac_cv_func_daxpy_"
13240 if test "x$ac_cv_func_daxpy_" = xyes; then :
13241
13242 else
13243   as_fn_error $? "BLAS library not installed correctly($with_blas)" "$LINENO" 5
13244 fi

Thanks

TK.

[Timo Heister]

You are just pointing at the error reporting. If you scroll up in
config.log you will see the program that configure tries to compile
and the corresponding compiler errors. That should help in figuring
out the problem.

[Ted Kord]

Hi Timo

In config.log, there are a few programs that failed but I'm not sure what their impact on the configure process is, i.e., are they ignored or not:

On line 180 (I explicitly disabled mpi so I'm guessin this particular error is ignored?!?):
conftest.cpp(13): catastrophic error: cannot open source file "mpi.h"
            #include <mpi.h>
                            ^
compilation aborted for conftest.cpp (code 4)

There were also a few failures of conftest.cpp and :

On line 1596:
configure:13239: checking for daxpy_
configure:13239: /opt/intel/composer_xe_2013.1.117/bin/intel64/icpc  -o conftest -DHAVE_ISNAN -g  -DBOOST_NO_HASH -DBOOST_NO_SLIST -DDEBUG -w1 -wd175 -wd525 -wd327 -wd424 -wd11 -wd734 -wd858 -wd1565 -wd1572 -std=c++0x -I/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include   -Wl,-rpath,/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include/lib -Wl,-rpath,/home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/lib -L/opt/intel/composerxe/mkl/lib/intel64 -lstdc++ -lpthread -lpthread -lpthread -ldl -rdynamic conftest.cpp -lz -lboost_thread-mt -lboost_serialization-mt   >&5
/tmp/icpci4i5d0.o: In function `main':
/home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/conftest.cpp:88: undefined reference to `daxpy_'
configure:13239: $? = 1

===

But daxpy is in libmkl_blas95_lp64:
Doing:  'nm libmkl_blas95_lp64.a' produces
daxpy.o:
                 U daxpy_
0000000000000024 T daxpy_f95_
0000000000000000 T daxpy_mkl95_
daxpyi.o:
                 U daxpyi_
0000000000000024 T daxpyi_f95_
0000000000000000 T daxpyi_mkl95_

I've attached config.log just in case.

Thanks

TK.

Best regards,

Theodore

[Timo Heister]

> In config.log, there are a few programs that failed but I'm not sure what
> their impact on the configure process is, i.e., are they ignored or not:

Yes, there are programs that are supposed to fail to check some behavior.

> On line 180 (I explicitly disabled mpi so I'm guessin this particular error
> is ignored?!?):
> conftest.cpp(13): catastrophic error: cannot open source file "mpi.h"
> #include <mpi.h>
> ^
> compilation aborted for conftest.cpp (code 4)

This is to check that we are not using mpi, so this is okay.

> On line 1596:
> configure:13239: checking for daxpy_

Okay, this is the test of interest.

> configure:13239: /opt/intel/composer_xe_2013.1.117/bin/intel64/icpc -o
> conftest -DHAVE_ISNAN -g -DBOOST_NO_HASH -DBOOST_NO_SLIST -DDEBUG -w1
> -wd175 -wd525 -wd327 -wd424 -wd11 -wd734 -wd858 -wd1565 -wd1572 -std=c++0x
> -I/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include
> -Wl,-rpath,/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include/lib
> -Wl,-rpath,/home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/lib
> -L/opt/intel/composerxe/mkl/lib/intel64 -lstdc++ -lpthread -lpthread
> -lpthread -ldl -rdynamic conftest.cpp -lz -lboost_thread-mt
> -lboost_serialization-mt >&5

^ This is the compilation command.

> But daxpy is in libmkl_blas95_lp64:

Well, but we are not linking with that library. So this is what you
need to fix. It seems that your --with-blas command is not working
correctly. Can you move the flags into -LDFLAGS instead and check
again?

[Ted Kord]

With this configure line:

./configure --enable-shared --disable-mpi --enable-threads --enable-multithreading --with-multithreading --with-umfpack LDFLAGS=-L/opt/intel/composerxe/mkl/lib/intel64 LDLIBS="-lmkl_blas95_lp64 -lmkl_lapack95_lp64" --with-boost=/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include

or this one:

./configure --enable-shared --disable-mpi --enable-threads --enable-multithreading --with-multithreading --with-umfpack LDFLAGS="-lmkl_blas95_lp64 -lmkl_lapack95_lp64" --with-boost=/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include

configure goes through but with:

checking for daxpy_... yes

checking for daxpy_... (cached) yes

checking for saxpy_... yes

checking for dgemv_... yes

checking for sgemv_... yes

checking for dgeev_... no

checking for sgeev_... no

checking for dgeevx_... no

checking for sgeevx_... no

checking for dgemm_... yes

checking for sgemm_... yes

checking for dgetrf_... no

checking for sgetrf_... no

checking for dgetri_... no

checking for sgetri_... no

checking for dgeqrf_... no

checking for sgeqrf_... no

checking for dormqr_... no

checking for sormqr_... no

checking for dorgqr_... no

checking for sorgqr_... no

checking for dtrtrs_... no

checking for strtrs_... no

checking for dgetrs_... no

checking for sgetrs_... no

checking for dstev_... no

checking for sstev_... no

checking for dsygv_... no

checking for ssygv_... no

checking for dsygvx_... no

checking for ssygvx_... no

checking for dsyevx_... no

checking for ssyevx_... no

checking for dgesvd_... no

checking for sgesvd_... no

checking for dgesdd_... no

checking for sgesdd_... no

checking for dgelsd_... no

checking for sgelsd_... no

checking for jn... yes

I can't understand why it's not finding these symbols.

TK.

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en

--
Best regards,

Theodore

[Timo Heister]

> I can't understand why it's not finding these symbols.

I am not sure why we are checking these symbols, but this is perfectly
fine. It looks the same on my machine. Try to compile and see if it
works.

[Ted Kord]

Compilation fails and all the errors relate to this (std::make_pair):

/home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/include/deal.II/lac/block_indices.h(410): error: no instance of function template "std::make_pair" matches the argument list

            argument types are: (int, unsigned int)

    return std::make_pair<unsigned int>(block, i-start_indices[block]);

           ^

I'm wondering if this is an issue with the Intel compiler itself.

Thanks

TK.

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en

--
Best regards,

Theodore

[Timo Heister]

Hey,

On Fri, Dec 21, 2012 at 4:26 AM, Ted Kord <teddy...@gmail.com> wrote:
> Compilation fails and all the errors relate to this (std::make_pair):
>
> /home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/include/deal.II/lac/block_indices.h(410):
> error: no instance of function template "std::make_pair" matches the
> argument list
> argument types are: (int, unsigned int)
> return std::make_pair<unsigned int>(block, i-start_indices[block]);
> ^

Can you try the following patch?

- return std::make_pair<unsigned int>(block, i-start_indices[block]);
+ return std::make_pair<unsigned int>(static_cast<unsigned int>(block),
+ i-start_indices[block]);

> I'm wondering if this is an issue with the Intel compiler itself.

No, this is a problem on our side. Please keep the reports coming.

[Ted Kord]

Hi Timo

The patch fixed that problem. Now, the error's :

/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include/boost/functional/hash/detail/hash_float.hpp(65): error: more than one instance of overloaded function "fpclassify" matches the argument list:

            function "fpclassify(double)"

            function "std::fpclassify(double)"

            argument types are: (double)

              switch (fpclassify(v)) {

                      ^

          detected during instantiation of "std::size_t={unsigned long} boost::hash_detail::float_hash_value(T) [with T=double]" at line 334 of "/home/tedkord/DEVELOPMENT_LIBRARIES/BOOST/include/boost/functional/hash/hash.hpp"

...

...

...

compilation aborted for /home/ismail/DEVELOPMENT_LIBRARIES/deal.II/source/dofs/dof_renumbering.cc (code 2)

NB: This error occurs with 'boost' built with the intel-compiler (used above) and with the boost version that comes with the deal.II library.

 

Thanks

TK.

On 21 December 2012 16:56, Timo Heister <hei...@math.tamu.edu> wrote:

return std::make_pair<unsigned int>(static_cast<unsigned int>(block),
+                                     i-start_indices[block]);

--
Best regards,

Theodore

[Timo Heister]

> error: more than one instance of overloaded function "fpclassify" matches
> the argument list:
> function "fpclassify(double)"
> function "std::fpclassify(double)"
> argument types are: (double)
> switch (fpclassify(v)) {

That looks like the compiler can not compile boost. You can try to
continue fixing problems. Here I would replace the call to fpclassify
with std::fpclassify or ::fpclassify.

[Ted Kord]

Thanks, that took care of that problem and the library compiled successfully/completely but I've had to temporarily replace (in parameter_handler.cc) all calls to:

std::numeric_limits<int>::min();

std::numeric_limits<int>::max();

std::numeric_limits<unsigned int>::max();

std::numeric_limits<double>::max();

with the hard-coded numerical values as the compiler kept complaining with errors like:

/home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/source/base/parameter_handler.cc(149): internal error: assertion failed: ensure_il_scope_exists: NULL IL scope (shared/cfe/edgcpfe/il.c, line 7439)

    const int Integer::min_int_value = std::numeric_limits<int>::min();

Any suggestions on a permanent fix?

Additionally, there were 'auto_ptr' warnings during the build, which also show up when building the examples:

/home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/include/deal.II/fe/fe_values.h(3015): warning #1478: class "std::auto_ptr<const dealii::FEValuesBase<2, 2>::CellIteratorBase>" (declared at line 87 of "/usr/include/c++/4.6/backward/auto_ptr.h") was declared deprecated

    std::auto_ptr<const CellIteratorBase> present_cell;

                                          ^

Many thanks

TK.

--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en

--
Best regards,

Theodore

[Wolfgang Bangerth]

It looks like it's finding the BLAS symbols but not the LAPACK ones. You
might have to look around how the LAPACK functions are called in the
Intel MKL you are linking with (the 'nm' program is your friend).

Best
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@math.tamu.edu
www: http://www.math.tamu.edu/~bangerth/

[Wolfgang Bangerth]

On 12/21/2012 04:26 AM, Ted Kord wrote:
> Compilation fails and all the errors relate to this (std::make_pair):
>
> /home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/include/deal.II/lac/block_indices.h(410):
> error: no instance of function template "std::make_pair" matches the
> argument list
> argument types are: (int, unsigned int)
> return std::make_pair<unsigned int>(block, i-start_indices[block]);
> ^
>
> I'm wondering if this is an issue with the Intel compiler itself.

I've checked in a variant of the patch Timo suggested for this.

[Wolfgang Bangerth]

On 12/22/2012 03:00 PM, Timo Heister wrote:
>> error: more than one instance of overloaded function "fpclassify" matches
>> the argument list:
>> function "fpclassify(double)"
>> function "std::fpclassify(double)"
>> argument types are: (double)
>> switch (fpclassify(v)) {
>
> That looks like the compiler can not compile boost. You can try to
> continue fixing problems. Here I would replace the call to fpclassify
> with std::fpclassify or ::fpclassify.

std::fpclassify is only part of C++ since C++11, so I've checked in a
patch to use ::fpclassify in this place.

[Wolfgang Bangerth]

On 12/22/2012 04:07 PM, Ted Kord wrote:
> Thanks, that took care of that problem and the library compiled
> successfully/completely but I've had to temporarily replace (in
> parameter_handler.cc) all calls to:
>
> std::numeric_limits<int>::min();
> std::numeric_limits<int>::max();
> std::numeric_limits<unsigned int>::max();
> std::numeric_limits<double>::max();
>
> with the hard-coded numerical values as the compiler kept complaining
> with errors like:
>
> /home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/source/base/parameter_handler.cc(149):
> internal error: assertion failed: ensure_il_scope_exists: NULL IL scope
> (shared/cfe/edgcpfe/il.c, line 7439)
>
> const int Integer::min_int_value = std::numeric_limits<int>::min();
>
> Any suggestions on a permanent fix?

Bummer, this is awkward. Does it work if you remove the two static
variables Integer::{min,max}_int_value altogether and simply use
std::numeric_limits<int>::min/max() in the initializers of the
Integer::Integer() constructor arguments? I don't think we use these
variables anywhere else...

> Additionally, there were 'auto_ptr' warnings during the build, which
> also show up when building the examples:
>
> /home/tedkord/DEVELOPMENT_LIBRARIES/deal.II/include/deal.II/fe/fe_values.h(3015):
> warning #1478: class "std::auto_ptr<const dealii::FEValuesBase<2,
> 2>::CellIteratorBase>" (declared at line 87 of
> "/usr/include/c++/4.6/backward/auto_ptr.h") was declared deprecated
> std::auto_ptr<const CellIteratorBase> present_cell;

What we should use is unique_ptr. The problem is that we use either the
C++11 facilities or the fallback BOOST classes (if the compiler doesn't
support C++11 yet) and BOOST doesn't have unique_ptr -- it has
scoped_ptr that offers the same functionality but with a different name.
This will require a bit of thinking.

I've opened a bug for this. Is there a way to turn off the warning for now?

As Timo said, thanks for looking into this -- keep the reports coming.