Compiling static Fortran library Qt
-
Hello everyone,
first I would like to say, that I am pretty new to the Qt, so please don't be harsh on me. I have Fortran files ( both header and source ) which I would like to compile to the static library. This library will be then used by the rest of the code.
Structure of the whole code looks like this:pro file model folder -pri file view folder -pri file controller folder -pri file fortran folder -pri file
where the last should be the static library. When I try to compile the static library I get the linker error 1104. The pri file looks as follows.
TEMPLATE = lib CONFIG += staticlib LIBS += lgfortran HEADERS += \ $$PWD/CPA_ALL.INC \ ... SOURCES += \ $$PWD/Auxiliary.for \ ...
And in the pro file I simply use include(Fortran/fortran.pri). I know that's probably completely wrong but I did not find any source which would push me a bit forward. Thank you for any suggestions.
-
qmake supports only C++. Build your fortran code using different build system, then in Qt app you can include the resulting library.
-
@sierdzio said in Compiling static Fortran library Qt:
qmake supports only C++.
Not strictly true. You can compile and link fortran, but it's a pain. You need to configure an extra compiler in the project file.
Build your fortran code using different build system, then in Qt app you can include the resulting library.
Probably a painless solution, indeed.
-
@kshegunov said in Compiling static Fortran library Qt:
You need to configure an extra compiler in the project file.
Oh right, that could work, I haven't thought about it. @Jakub-Srna here is the documentation for extra compilers feature https://doc.qt.io/qt-5/qmake-advanced-usage.html#adding-compilers
-
Thank you very much, both of you. So I made a bit of googling and got to a point, where I get this
'gfortran' is not recognized as an internal or external command, operable program or batch file.
I know what it means, just I don't know why I get it.
TEMPLATE = lib CONFIG += staticlib LIBS += -lgfortran gfortran.input = SOURCES \ HEADERS gfortran.commands = gfortran $${FORTRAN_FLAGS} ${QMAKE_FILE_NAME} -c -o ${QMAKE_FILE_OUT} gfortran.output = ${QMAKE_FILE_BASE}.o QMAKE_EXTRA_COMPILERS += gfortran HEADERS += \ $$PWD/CPA_ALL.INC \ .... SOURCES += \ $$PWD/Auxiliary.for \ ....
This is the updated version of the pri file. I am a bit confused as the library -lgfortran is apparently included as it should but it's not recognized when it should. Any ideas how should I continue? I am on Windows machine MSVC 2017.
-
Personally I would go for a painlesser option as already suggested above. Make a library and use it for linking with C/C++.
Anyway probably gfortan command cannot be found because it is not known in the environment. You can set the project's build environment under "Projects"->"Build Settings". On this page at the end is the "Build environment". Typically there are the settings copied from System's environment, but you can add there what is required.
Certainly you could also simply spoil your system's environment by additional settings and path extensions. However, extending the build environment keeps things cleaner.
-
Personally I would go for a painlesser option as already suggested above. Make a library and use it for linking with C/C++.
As @koahnig and others mention, I guess if that you're able to build a library for use with C/C++ with your Fortran code externally to Qt, it would save you time and effort...
-
@Jakub-Srna said in Compiling static Fortran library Qt:
I am a bit confused as the library -lgfortran is apparently included as it should but it's not recognized when it should. Any ideas how should I continue?
The error is about your compiler, not so much about the library. What you need to do is to have a separate variable, separate from
SOURCES
andHEADERS
that is, which lists your fortran source code files, and which you pass as input to the compiler. Also, and I cite from memory here, you need to "trick"qmake
to add the generated object files from the extra compiler to the already existing list of object files, so linking to go as expected. Unfortunately I couldn't find an example to give you, I must've deleted it or put it somewhere, so I have to rely on memory ...As a side question, are we talking about mixing fortran and C/C++ or are you using
qmake
as a make generator only? -
Thank you all for your replies. I am sorry @kshegunov but I did not get the side question. But the way I understood I say yes, mixing the code. C++ is used to create the interface and Fortran holds all the advanced mathematical calculations.
Also, I got a step further. Was stupid and used MSVC and the gfortran, which is included just in the MinGW compiler. Got part of it compiled but at the same time getting plenty of errors. Guess that this is caused by the set flags.
To make the picture complete I developed the app in the Visual Studio before and I have the intel fortran in my PC. Can I include that somehow as I know it optimizes the code more?And hopefully one of my last questions. When I use either gfortran or ifort in my code and I'll try to do the cross compilation. Will the fortran part of the code run flawlessly on Mac or Linux?
Thank you a lot
-
Guess that this is caused by the set flags.
I don't know.
Can I include that somehow as I know it optimizes the code more?
Fortran uses C-linkage so any linker should be able to manage it.
Note that fortran mandates decoration of the function names itself, because reasons. So if you have:subroutine dummy() end subroutine dummy
This is seen by the linker as if it was defined as
void dummy_()
.
If you intend to call fortran from C, you must provide the proper declarations for the compiler in your C code, they can't be deduced automatically.When I use either gfortran or ifort in my code and I'll try to do the cross compilation. Will the fortran part of the code run flawlessly on Mac or Linux?
As long as you configure the compiler properly, you can treat fortran code as any other C code, so it should work fine, yes.
Tangent:
gfortran
, I believe, still transpiles the fortran source to C and then runs the C compiler on top of it. In the end why should anyone invest time into keeping a real compiler for a zombie language up to date ...