Creating a QMAKE project for a Fortran dynamic library in Mac OS X
-
Dear all,
Please Help. This is something that is bugging me for months. At the beginning I tried Makefiles. Then I said to myself: "Lets grab CMAKE and try it out". I dropped it. Then it was SCONS; looked really nice, but it doesn't create Xcode projects. Then I gave another try to CMAKE for a few days, but it is so complicated that I dropped it once again. These things are supposed to make our life easier; so anything more complicated than a Makefile should not be out there. I tried QMAKE. In 5 min, I was able to compile. Then I went a step forward and tried to create a library, a Fortran dynamic library under OSX. If QMAKE passes this test I am going to use it until the end of the days. Here is my Mine.pro.@CONFIG -=qt
CONFIG += fortran
TEMPLATE = libunix:OBJECTS_DIR = obj
The following is needed, otherwise I have linking errors, which I should not, since I am creating a library
unix:LIBS += -L/opt/local/lib/gcc49 -lgfortran
CONFIG(debug, debug|release) {
FORTRAN_FLAGS = -g -O0
} else {
FORTRAN_FLAGS = -O2
}fortran.name = FORTRAN compiler
fortran.input = FORTRAN_SOURCES
fortran.output = ${OBJECTS_DIR}${QMAKE_FILE_BASE}.o
fortran.commands = gfortran-mp-4.9 ${FORTRAN_FLAGS} -c ${QMAKE_FILE_NAME} -o ${QMAKE_FILE_OUT}FORTRAN_SOURCES+= src/file1.f
@
This works. The library with this Mine.pro file was successfully created as you can see below.bq. gfortran-mp-4.9 -c src/file1.f -o obj/file1.o
rm -f libMine.1.0.0.dylib libMine.dylib libMine.1.dylib libMine.1.0.dylib
/usr/bin/clang++ -headerpad_max_install_names -arch x86_64 -single_module -dynamiclib -compatibility_version 1.0 -current_version 1.0.0 -install_name libMine.1.dylib -Xarch_x86_64 -mmacosx-version-min=10.8 -o libMine.1.0.0.dylib obj/file1.o -L/opt/local/lib/gcc49 -lgfortran
ln -s libMinos.1.0.0.dylib libMinos.dylib
ln -s libMinos.1.0.0.dylib libMinos.1.dylib
ln -s libMinos.1.0.0.dylib libMinos.1.0.dylibBut why clang is invoked and not libtool or something that is meant for creating libraries? Moreover, I have other problems:
bq. $ otool -L libMine.dylib
libMine.dylib:
libMine.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/opt/local/lib/libgcc/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0)
/opt/local/lib/libgcc/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.20.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)The problem is that my library has included libgfortran. If another machine where this library is installed, does not have libgfortran installed on the same directory, I will get a stupid error when running any executable linked against my library. I had the same issues on OS X with MKL BLAS. If this library was linked against MKL-BLAS, distributing my Library would distribute MKL-BLAS as well . How can I avoid this? What should I add in the qmake configuration?
That's all folks, ( for now )
Thanks for your time.
Panos. -
Hi and welcome to devnet,
If you are distributing the library alone, you can't really avoid it, one would need to run install_name_tool to correct the path. However did you consider creating a framework ? So you could deliver everything in one place.
Hope it helps
-
Hi there.
It should be possible somehow. The problem is that it is not documented well enough. When you compile a library you do not normally need to specify dependent libraries like I am doing here. At least in Linux you do not. I suspect that there must be a way to do the same on OSX.
-
By the way, how can I tell to QMAKE to place the library in a subdirectory named
bq. lib/
Does anybody know how can I use "console-type" frame instead of "code" and "quote" that is provided here?
-
@DESTDIR =@
Using install_name_tool you can modify the paths, but at some point your using would need to have DYLD_LIBRARY_PATH pointing to the folder where libgfortran is or you bundle it yourself so they don't even need to install it