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=/usr/local/opt/lapack/lib/ ). Unfortunately, sinocos/FindLAPACK.cmake <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fsiconos%2Fsiconos%2Fblob%2Fmaster%2Fcmake%2FFindLAPACK.cmake&sa=D&sntz=1&usg=AFQjCNHbqZbSIXPM3Nvv_ZmEm0dA9YlNBQ> introduces some conflicts, besides the need of FindBLAS.cmake which is minor. It would be interesting to sort this out for all mac users that need to link to lapacke, but my knowledge of cmake is so far limited. I sorted out by adding my lapacke path by hand, in the meanwhile. Thank you! Alberto
Il giorno martedì 28 marzo 2017 02:57:08 UTC-4, Jean-Paul Pelteret ha scritto: > > 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 external library > itself has other dependencies, then it ensures that all of those > dependencies are also correctly linked against. So its the most fool-proof > approach to making sure that you don't run into build issues now nor > further down the line. > > I see that CMake ships with a module to find Lapack, but using it sensibly > is not actually as straight forward as it could be :-/ So I've setup an > example based on step-1 (attached) that calls some Lapack functions. These > functions are marked as "external" since I don't appear have the lapacke.h > header on my machine. If you look at CMakeLists.txt for this example, > below the DEAL_II_INVOKE_AUTOPILOT() line are all of the commands > necessary to link to a generic Lapack installation. Unfortunately the > standard FindLAPACK module that CMake provides does not accept hints for > the path to Lapack, so I borrowed a work-around > <https://github.com/dealii/dealii/blob/master/cmake/modules/FindLAPACK.cmake#L34> > > for this from our own module. > > To configure this example, you would first run > > cmake -DDEAL_II_DIR=/path/to/deal.II . > which would then autodetect any lapack installation in path. If you need > to specify the location of the lapack installation, you could run > cmake -DLAPACK_DIR=/path/to/lapack -DDEAL_II_DIR=/path/to/deal.II . > instead. > > Please let me know if this resolves the problem for you. > > Best, > Jean-Paul > > >> Hi, I was too rushy. It is not working yet. >> Let me see if I understand. I do know where my mkl libraries are, but if >> I edit the cmakelist.txt file with >> target_link_libraries(code_exe ${lapackblas_libraries} >> I have an error message. So, basically, I do not know how to instruct >> Cmake how to link lapack libraries. Would findlapack.cmake sort it out? If >> so, can you suggest how to edit the step-18 cmakelist? I really appreciate >> your help with this issue. >> Alberto > > > On Tuesday, March 28, 2017 at 1:49:08 AM UTC+2, Alberto Salvadori wrote: >> >> 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....@unibs.it <javascript:> >> web-pages: >> http://m4lab.unibs.it/faculty.html >> http://dicata.ing.unibs.it/salvadori >> >> On Mon, Mar 27, 2017 at 10:48 AM, Jean-Paul Pelteret <> wrote: >> >>> 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 to >>> build deal.II with Lapack enabled. You can do this my adding the following >>> lines to the configuration line for deal.II: >>> cmake -DDEAL_II_WITH_LAPACK:BOOL=ON -DLAPACK_DIR=/path/to/lapack etc... >>> Then every time that you link against the deal.II library, it will >>> automatically link against LAPACK. >>> >>> Otherwise if you're really prefer to keep it local to your project then >>> you'd best do it by adding a cmake module such as this one >>> <https://github.com/Kitware/CMake/blob/master/Modules/FindLAPACK.cmake>. >>> These will help you include all of the header files into your project that >>> you need to, as well as correctly link the LAPACK library (and any of its >>> dependencies) itself. >>> >>> I hope that this helps you. >>> >>> Best regards, >>> Jean-Paul >>> >>> >>> On Monday, March 27, 2017 at 4:07:17 PM UTC+2, Alberto Salvadori wrote: >>>> >>>> Hi, >>>> >>>> >>>> I appreciate any help on the issue below. >>>> >>>> >>>> Moving from step-17 and step-18, I have been developing a non linear >>>> solver for mechanical problems. It is a way to learn about deal.II rather >>>> than else. Conceptually it is rather simple, I have implemented some >>>> material model drivers (as J2 plasticity, for instance ) and a >>>> Newton-Raphson scheme. >>>> >>>> >>>> In my material model however, I am using lapack (specifically lapacke >>>> or mkl). It turned out that I am not sufficiently skilled to modify the >>>> cmake file in order to link deal.II with those libraries. I wonder if >>>> anyone can provide some help. >>>> >>>> The error reads as follows: >>>> >>>> >>>> [ 22%] *Linking CXX executable step-18* >>>> >>>> Undefined symbols for architecture x86_64: >>>> >>>> "_LAPACKE_dgesv", referenced from: >>>> >>>> ttl::lib::solve_impl<ttl::expressions::Bind<ttl::Tensor<4, 2, >>>> double> const&, std::__1::tuple<ttl::Index<(char)4>, ttl::Index<(char)3>, >>>> ttl::Index<(char)2>, ttl::Index<(char)1> > >, >>>> ttl::expressions::Bind<ttl::Tensor<2, 2, double> const&, >>>> std::__1::tuple<ttl::Index<(char)2>, ttl::Index<(char)1> > >, >>>> 4>::op(ttl::expressions::Bind<ttl::Tensor<4, 2, double> const&, >>>> std::__1::tuple<ttl::Index<(char)4>, ttl::Index<(char)3>, >>>> ttl::Index<(char)2>, ttl::Index<(char)1> > >, >>>> ttl::expressions::Bind<ttl::Tensor<2, 2, double> const&, >>>> std::__1::tuple<ttl::Index<(char)2>, ttl::Index<(char)1> > >) in >>>> step-18.cc.o >>>> >>>> "_LAPACKE_dgetrf", referenced from: >>>> >>>> int ttl::lib::inverse_impl<ttl::expressions::Bind<ttl::Tensor<4, >>>> 2, double> const&, std::__1::tuple<ttl::Index<(char)4>, >>>> ttl::Index<(char)3>, ttl::Index<(char)2>, ttl::Index<(char)1> > >, >>>> 4>::op<ttl::Tensor<4, 2, double> >(ttl::expressions::Bind<ttl::Tensor<4, >>>> 2, >>>> double> const&, std::__1::tuple<ttl::Index<(char)4>, ttl::Index<(char)3>, >>>> ttl::Index<(char)2>, ttl::Index<(char)1> > >, ttl::Tensor<4, 2, double>&) >>>> in step-18.cc.o >>>> >>>> "_LAPACKE_dgetri", referenced from: >>>> >>>> int ttl::lib::inverse_impl<ttl::expressions::Bind<ttl::Tensor<4, >>>> 2, double> const&, std::__1::tuple<ttl::Index<(char)4>, >>>> ttl::Index<(char)3>, ttl::Index<(char)2>, ttl::Index<(char)1> > >, >>>> 4>::op<ttl::Tensor<4, 2, double> >(ttl::expressions::Bind<ttl::Tensor<4, >>>> 2, >>>> double> const&, std::__1::tuple<ttl::Index<(char)4>, ttl::Index<(char)3>, >>>> ttl::Index<(char)2>, ttl::Index<(char)1> > >, ttl::Tensor<4, 2, double>&) >>>> in step-18.cc.o >>>> >>>> ld: symbol(s) not found for architecture x86_64 >>>> >>>> clang: *error: *linker command failed with exit code 1 (use -v to see >>>> invocation) >>>> >>>> make[6]: *** [step-18] Error 1 >>>> >>>> make[5]: *** [CMakeFiles/step-18.dir/all] Error 2 >>>> >>>> make[4]: *** [all] Error 2 >>>> >>>> make[3]: *** [CMakeFiles/release] Error 2 >>>> >>>> make[2]: *** [CMakeFiles/release.dir/all] Error 2 >>>> >>>> make[1]: *** [CMakeFiles/release.dir/rule] Error 2 >>>> >>>> make: *** [release] Error 2 >>>> >>>> after slight modifications of the cmakelist.txt file (adding the new >>>> source files, basically). >>>> >>>> >>>> By the way, I was able to link libraries to deal.II within Xcode and it >>>> worked out well. >>>> >>>> >>>> Thanks >>>> >>>> Alberto >>>> >>> -- >>> 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 >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "deal.II User Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to dealii+un...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> Informativa sulla Privacy: http://www.unibs.it/node/8155 >> > -- Informativa sulla Privacy: http://www.unibs.it/node/8155 -- 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 --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
