Makefile: no rule to build m_cli2 shared library
band-a-prend opened this issue · comments
The current Makefile doesn't provide rule to build m_cli2 shared library that results in impossibility to use M_CLI2 as unbundled package or module (system installed) due to undefined reference errors.
Using gfortran I had to build it manually initially passed into F90FLAGS of Makefile the option -fPIC to build proper object file M_CLI2.o that than could be linked to shared (passing it's SONAME too) library by
gfortran -Wl,-soname,libm_cli2.so.1 -shared -o libm_cli2.so.1 M_CLI2.o
and then creating symlink libm_cli2.so pointed to libm_cli2.so.1.
Please add additional Makefile rules to build shared library for appropriate compilers.
It should be totally useable as a *.a and *.mod file and be statically linked successfully even in an otherwise dynamically loaded executable; but it would be nice to have an optional shared library build as well. Personally I always statically load it and the Makefile is an example for a few common programming environments where I expect some people will have to customize it; but this seems like a good additional option that would be good for several other packages I have as well.
I tried to package fpm for Gentoo (sourced based linux distributive) GURU repository (users repo, like Arch Linux AUR) and in Gentoo it's usual to use dinamicaly linked libraries on build process.
The problem was that in Gentoo building of package processes within networkless sandbox therefore I had to unbundle fpm dependencies (toml-f and m_cli2) as it's assumed to be downloaded via git. After some fpm.toml patching and packaging toml-f, m_cli2 as separate packages/libraries they are dinamicaly linked on fpm build for me. Resulting fpm looks working so waiting these three packages merging to Gentoo GURU repository.
Sorry, I too rare write build scripts like make build system so I couldn't quickly provide patch for Makefile to build shared library.
I took a first pass at it for gfortran, but had not seen your reply. fpm(1) is generally designed to rebuild everything from source to avoid some of the issues that result from using multiple Fortran compilers; so in general for self-contained programs you want to avoid making libraries external. On the other hand you do not want to rebuild everything all the time, especially with programs that use large packages such as MPI, X11 Windows, and so on; but just be aware that not all Fortran compilers generate libraries that can be used by other Fortran compilers or even by the same compiler with different switches used; if you have not run into that issue before.
Anyway, I made some draft changes to the makefile so it defaults to acting essentially as it did, but has a special mode for gfortran where if you enter "make clean gfortran gfortran_install" it builds a directory called libgfortran with everything in it.
Also note that if you are using fpm(1) you should just be able to have a copy of the project and run "fpm install" and install the static library and *.mod files in your default fpm build directory. That is how it is designed to work in it's purest form.
Your situation is something I had not considered, so I will try to keep that in mind in redesigning the Makefile.
You can also copy all the dependencies an fpm program needs into subdirectories in the root of the project, and then the dependencies can be changed to be local, which is an easier way (probably) to build on a platform without network connectivity,
and that there is also a single-file version of fpm you can build that is just one big Fortran file on the download page. The description of the manifest file fpm.toml describes local dependencies (which can be links instead of copies).
Sorry for too long delay with feedback.
I finally check new build method and built shared library as it's described in example.
After passing additional gfortran_install the full set of .mod, .a, .so.1 (with symlink) are presented within libgfortran subdirectory.
As early after installation of m_cli2 library into system it's successfully links with fpm and fpm passes the tests.
I.e. both m_cli2 and fpm build processes are managed for me by Gentoo Linux package manager so build of shared library could be useful t other distributives maintainers.
Great thanks!
P.S.
Could the issue be closed as resolved?
Yes. The goal was to make something that worked for you. If it works you can close this. There are some other things I want to do as a result in other packages, but that is a separate issue. Good to hear it worked. I was not familiar with the Gentoo packaging requirements. I will try to keep that in mind for other projects. Thanks!