Re: [deal.II] Re: linking to lapacke

2017-03-28 Thread Alberto Salvadori
Jean-Paul, this was useful. Now cmake finds lapack ( I added also -DBLA_VENDOR=Generic otherwise cmake loads the Apple framework ) but it is not lapacke, as Denis was pointing out. ( BTW, it seems also that cmake finds lapack in a directory that is different from the one input by -DLAPACK_DIR=/u

[deal.II] Re: linking to lapacke

2017-03-28 Thread Alberto Salvadori
You are right, Denis. In fact, though, sinocos/FindLAPACK.cmake introduces some conflicts, besides the need of FindBLAS.cmake

[deal.II] Re: linking to lapacke

2017-03-28 Thread Denis Davydov
Hi Alberto, My understanding is that CMake does not provide any interface to find Lapacke ("e" is important here) within their FindLAPACK https://github.com/Kitware/CMake/blob/master/Modules/FindLAPACK.cmake . So one would need to write extra code to pick-up lapacke.h and all. AFAIK it's not

Re: [deal.II] Re: linking to lapacke

2017-03-27 Thread Jean-Paul Pelteret
Dear Alberto, Using CMake modules is generally the best approach to take, because it means that you do not hard-code the library locations into your program setup, and it thus remains portable for both code distribution and when you update any libraries that you use. Furthermore, if this exter

Re: [deal.II] Re: linking to lapacke

2017-03-27 Thread Alberto Salvadori
Thank you, Jean-Paul, it was very useful. It works well. Alberto *Alberto Salvadori* Dipartimento di Ingegneria Civile, Architettura, Territorio, Ambiente e di Matematica (DICATAM) Universita` di Brescia, via Branze 43, 25123 Brescia Italy tel 030 3711239 fax 030 3711312 e-mail: alberto.sal

[deal.II] Re: linking to lapacke

2017-03-27 Thread Jean-Paul Pelteret
Hi Alberto, So, if I understand correctly, you've made modifications to the CMakeLists.txt that governs your modified example problem as opposed to linking deal.II itself directly to Lapack. I would say that the most simple (although time-consuming) way to get the correct linker line would be t