Hello all,
I am working on some Fortran code which calls an additional function from a DLL (dynamic link library). In order for the code to work under Linux, it must be possible to read in SO (shared library) files in addition to the DLLs. The DLL and SO are generated from C++ code. The C++ code itself is not very complicated, i.e. no objects, etc.
Unfortunately, I can hardly find any information on how the SO files can be used in Fortran. I would be very grateful for any advice.
Shared object files (libraries) are usually stored in the same directory as the executable or in /usr/lib/ (Linux) or /usr/local/lib/ (Unix). When compiling your Fortran project, you just link dynamically against your library, for instance, for a code file test.f90 and a library libdummy.so:
$ gfortran -o test test.f90 -ldummy
In addition to @interkosmos answer, if your dynamic library is outside of your current compile directory and not in one of the default searched locations, you will have to use the -L option to direct the linker to the .so
gfortran -Wall -o test test.f90 -L/path/to/lib -ldummy
Let me add a bit more even:
- On Linux it is common to call libraries something like “libmylib.a” for static libraries and “libmylib.so” for shared library (DLLs in Windows parlance). Then the compile/link option -lmylib will find these libraries.
- While it is common, it is by no means mandatory. You can still name your library mylib.a or mylib.so (the extensions are conventions as well as far as I know, but do no tmess about with them, because otherwise the result will indeed be a mess).
- The conventions mentioned above play a role with certain details of the linking process, like preferring staitc over dynamic/shared libraries or vice versa.
- Unlike the typical situation on Windows, linkers on Linux do not require a separate import library. On Windows you would have mylib.lib as the import library and mylib.dll as the actual dynamic library.
- Shared/dynamic libraries and static libraries on Linux are very similar at compile/link time, though not at runtime.
1 Like
Hello all,
sorry for reopening this discussion but I need your advise.
I share a code with several users. This code is linked against a dynamic library.
Let’s suppose that the code (mycode) and the library (libmylib.so) are located on /soft/src and compiled as:
gfortran -L/soft/src -lmylib -o mycode.exe mycode.f90
Users have the read/execute permissions on /soft/src but not write permission.
This is where it gets a little more complicated: the code allows the user (according to his needs) to create, on his current directory, a new version of the library (execute_command_line is used to compile it) and deleted when the code terminate.
The code should therefore be linked against this new library.
Naively I thought that it was possible to invoke several directories with the -L flag (e.g. gfortran -L. -L/soft/src -lmylib -o mycode.exe mycode.f90) and that, at runtime, the library would be “picked” from one of these directories (looking for it in the given order) but it does not work.
The only trick I found to do this (without bothering non-specialist users) is to use a script:
cat /soft/mycode
# Make a copie of DYLD_LIBRARY_PATH:
save=$DYLD_LIBRARY_PATH
# Add (in this order) the current directory and the directory of the initial libmylib
export DYLD_LIBRARY_PATH=.:/soft/src:$DYLD_LIBRARY_PATH
# Execute mycode.exe:
/src/soft/mycode.exe
# Restore DYLD_LIBRARY_PATH:
DYLD_LIBRARY_PATH=$save
but perhaps there is a better and more elegant solution.
@riadh, welcome to the forum!
A quick reply:
It sounds as if you need to explicitly load and unload the dynamic library. An easier alternative is to compile the library and then execute the program that actually uses that with the program that controls all this simply functioning as a front-end.
Thank you Arjen.
Yes, but in this case the users have to compile the library themselves (this is what I wanted to avoid: asking non-expert users to have to compile or modify their environment variables).
What I mean is:
- You have a front-end program that presents itself to the user as THE program.
- The user can offer it the source code to be run
- The front-end program runs a shell script/batch file to build the library as a .so/DLL. It is actually built in a convenient directory, not the installation directory, and then starts the actual computation.
- Any environment variables that need to be set can be set in the shell script/batch file, no need for the user to worry about it. That might include setting the PATH or LD_LIBRARY_PATH variables to the working directory so that the new library is picked up.
Well, just a sketch. But there are technical difficulties to unload a library, which I thought you were thinking of. Not all OSes can handle that, if I am not mistaken. With the above solution direction there will be a lot of details to sort out, but none that are really difficult.