Adding external library to libdeal_II

[Victor Magri]

Hello,

I have a solver library (in shared format, let's say libmylib.so) that I would like to link to deal.II. In order to do this, I checked how the METIS library is added to libdeal_II and tried to do the same for my library, thus I added the files configure_my_lib.cmake and FindMylib.cmake under cmake/configure and cmake/modules, respectively. 

Strange thing is that in the output of build/CMakeCache.out I find:

DEAL_II_WITH_MYLIB:BOOL=ON
MYLIB_DIR:PATH=/marconi/home/userexternal/vpaludet/projects/mylib

MYLIB_INCLUDE_DIR:PATH=/marconi/home/userexternal/vpaludet/projects/mylib/include 

MYLIB_LIBRARY:FILEPATH=/marconi/home/userexternal/vpaludet/projects/mylib/lib/libmylib.so

deal_II_LIB_DEPENDS:STATIC=general;/cineca/prod/opt/libraries/lapack/3.6.1/intel--pe-xe-2017--binary/lib/liblapack.a;general;/cineca/prod/\

    opt/libraries/blas/3.6.0/intel--pe-xe-2017--binary/lib/libblas.a;general;imf;general;m;general;ipgo;general;irc;general;pthread;general;sv\

    ml;general;irc_s;general;c;general;dl;general;/lib64/libz.so;general;/marconi/home/userexternal/vpaludet/projects/mylib/lib/libmylib.so \

    ;general;/marconi/home/userexternal/vpaludet/lib/libmetis.so;general;/cineca/prod/opt/libraries/boost/1.61.0/intelmpi--2017--\

    binary/lib/libboost_iostreams.so;general;/cineca/prod/opt/libraries/boost/1.61.0/intelmpi--2017--binary/lib/libboost_serialization.so;gene\

    ral;/cineca/prod/opt/libraries/boost/1.61.0/intelmpi--2017--binary/lib/libboost_system.so;general;/cineca/prod/opt/libraries/boost/1.61.0/\

    intelmpi--2017--binary/lib/libboost_thread.so;general;/cineca/prod/opt/libraries/boost/1.61.0/intelmpi--2017--binary/lib/libboost_regex.so\

    ;general;/cineca/prod/opt/libraries/boost/1.61.0/intelmpi--2017--binary/lib/libboost_chrono.so;general;/cineca/prod/opt/libraries/boost/1.\

    61.0/intelmpi--2017--binary/lib/libboost_date_time.so;general;/cineca/prod/opt/libraries/boost/1.61.0/intelmpi--2017--binary/lib/libboost_\

    atomic.so

However, when I run "ldd build/lib/libdeal_II.so" I get:

linux-vdso.so.1 =>  (0x00007ffcbc1f5000)

libimf.so => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/lib/intel64/libimf.so (0x00007f4e5fd11000)

libirc.so => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/lib/intel64/libirc.so (0x00007f4e5faa7000)

libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f4e5f874000)

libsvml.so => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/lib/intel64/libsvml.so (0x00007f4e5e95b000)

libc.so.6 => /lib64/libc.so.6 (0x00007f4e5e598000)

libdl.so.2 => /lib64/libdl.so.2 (0x00007f4e5e394000)

libz.so.1 => /lib64/libz.so.1 (0x00007f4e5e17e000)

libmetis.so => /marconi/home/userexternal/vpaludet/lib/libmetis.so (0x00007f4e5dec4000)

libstdc++.so.6 => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/inspector/lib64/libstdc++.so.6 (0x00007f4e5dba5000)

libgcc_s.so.1 => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/inspector/lib64/libgcc_s.so.1 (0x00007f4e5d98e000)

libintlc.so.5 => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/lib/intel64/libintlc.so.5 (0x00007f4e5d722000)

/lib64/ld-linux-x86-64.so.2 (0x00007f4e670df000)

libm.so.6 => /lib64/libm.so.6 (0x00007f4e5d420000)

libmpifort.so.12 => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/impi/2017.3.196/lib64/libmpifort.so.12 (0x00007f4e5d076000)

libmpi.so.12 => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/impi/2017.3.196/lib64/libmpi.so.12 (0x00007f4e5c34e000)

librt.so.1 => /lib64/librt.so.1 (0x00007f4e5c146000)

libirng.so => /cineca/prod/opt/compilers/intel/pe-xe-2017/binary/lib/intel64/libirng.so (0x00007f4e5bdd0000)

and I don't see my library there. On the other hand, If I try to compile an executable, let's say step-3, and run ldd on it I see that it's linked to libdeal_II.so and also libmylib.so. My question is why my library can be seen only by the executable and not by libdeal_II.

Thank you for helping and I'm sorry if I didn't provide enough details about this problem. Let me know if you need more data :)

Best!!

[Jean-Paul Pelteret]

Dear Victor,

Can you clarify something: Have you modified a copy of deal.II such that your library is now an explicit dependency (i.e. deal.II now has some function calls to your library), or is your library only being referenced through some functions called inside another code (e.g. "step-3" as per your example)?

Best,

J-P

[Victor Magri]

Hello Jean-Paul, sorry for not being clear about this... Answer is the first option. 

I'm using the development version of libdeal.II and I added an interface for calling my solver under include/lac/mysolver.h (In the solve method I have a call to a function defined in my library). 

Thank you!

[Jean-Paul Pelteret]

Hi Victor,

No problem :-) So have you just added an extra header and no source? If so then there's no compilation unit within deal.II that references your library. I bet if you added an associated .cc file with your function definitions and then recompiled deal.II then you'd see deal.II being linked against it. If your amendment to the library is "header-only" then the definitions (i.e. those that finally reference your library itself) are only needed when compiling your final executable.

Best,

J-P

[Wolfgang Bangerth]

On 07/04/2017 08:01 AM, Victor Magri wrote:
> Hello Jean-Paul, sorry for not being clear about this... Answer is the first
> option.
>
> I'm using the development version of libdeal.II and I added an interface for
> calling my solver under include/lac/mysolver.h (In the solve method I have a
> call to a function defined in my library).

That seems like the more complicated version, compared to putting the new
solver into your own project -- any reason to put it there?

Cheers
W.

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

[Victor Magri]

Dear Jean-Paul,

I followed your advice and separated interface from implementation of the wrapper for calling my solver. I deleted the build folder that I was using and run cmake/make/make install again but the produced libdeal_II.so still doesn't see my library as can be seen from the output of "ldd build/lib/libdeal_II.so" (In this build I have also changed platform and compiler) :

linux-vdso.so.1 =>  (0x00007ffd8dd9b000)

liblapack.so.3 => /usr/lib/liblapack.so.3 (0x00007fee6856b000)

libblas.so.3 => /usr/lib/libblas.so.3 (0x00007fee682fc000)

libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fee680ac000)

libmetis.so => /usr/lib/libmetis.so (0x00007fee67e3b000)

libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fee67ab1000)

libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fee677a8000)

libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fee673dd000)

libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fee671c6000)

libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fee66fa9000)

libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3 (0x00007fee66c77000)

/lib64/ld-linux-x86-64.so.2 (0x00005587695e8000)

libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0 (0x00007fee66a37000)

Although, when I looked to build/source/CMakeFiles/deal.II.dir/link.txt (attached) I found that my library (libmysolver.so) should have been linked to libdeal.II.so and I don't understand why libmysolver.so does not appear in the dependencies of libdeal_II. Would you have some hypothesis on that? 

Another think that I noted is that the file mysolver.cc that I added under source/lac is not being compiled and linked to libdeal_II.so (I could not find it in the link.txt file that I attached). Do I need to do something else in order to cmake recognize that this file need to be compiled and linked to libdeal_II?

I appreciate your help!

[Victor Magri]

Dear Professor Bangerth,

The problem that I'm interested in solving is multi-physical and thus I'm handling with block matrices. These are treated in a particular way inside my library which is different than the BlockSparseMatrix type defined in deal.II. So the idea was to create interfaces for calling my solver and also for building the block matrices according to the data structure that I need for running my solver. Digging into the library I saw that a similar thing is done for the integration of PETSc and Trilinos to deal.II. Then I tried to follow how their integration is done and apply it for my solver. Please, let me know if this is not the best approach :)

Best!

[Jean-Paul Pelteret]

Hi Victor,

Another think that I noted is that the file mysolver.cc that I added under source/lac is not being compiled and linked to libdeal_II.so (I could not find it in the link.txt file that I attached). Do I need to do something else in order to cmake recognize that this file need to be compiled and linked to libdeal_II?

Have you added this source file to "source/lac/CMakeLists.txt"? If your additions are not being compiled, then the definitions provided by your library are not needed to build deal.II itself. So it need not be linked against when building the final library files.

Although, when I looked to build/source/CMakeFiles/deal.II.dir/link.txt (attached) I found that my library (libmysolver.so) should have been linked to libdeal.II.so and I don't understand why libmysolver.so does not appear in the dependencies of libdeal_II. Would you have some hypothesis on that? 

Fix the point above and then this would hopefully address this issue.

That seems like the more complicated version, compared to putting the new 
solver into your own project -- any reason to put it there? 

I'm with Wolfgang on this one, but I didn't bring it up since its not the question that you asked. If you don't need to make any fundamental alterations to the deal.II library in order to implement your specialised solver then it is not necessary to integrate it directly into deal.II. Assuming that you're not planning on contributing this code back to deal.II, you'd be causing yourself more trouble in the long run since you'd (presumably) have to maintain your special branch as we continue to update itself.

I'm not sure if you've seen it, but we have a portion of the documentation dedicated to explain how to add external dependencies to a user project. Perhaps it'll be of some use to you, and help you avoid this path that you're taking altogether.

Best,

J-P

 

[Victor Magri]

Have you added this source file to "source/lac/CMakeLists.txt"? If your additions are not being compiled, then the definitions provided by your library are not needed to build deal.II itself. So it need not be linked against when building the final library files.

Perfect, Jean-Paul. It was a very silly mistake of mine to don't add it. The problem is resolved now and I can see my library in the list of libdeal_II dependencies.

I'm not sure if you've seen it, but we have a portion of the documentation dedicated to explain how to add external dependencies to a user project. Perhaps it'll be of some use to you, and help you avoid this path that you're taking altogether.

 

Thank you for pointing this. I came to know this portion of the documentation after I had already started to follow the other way and probably at a first step towards integration this would be the best path to follow. Anyway, if things get harder from now on I will switch to this approach. When everything works great, I hope to contribute these interfaces to the deal_II community.

I appreciate your help Jean-Paul! 

Best!