# Including Linux .so-files in Fortran programs

**URL:** <https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451>\
**Category:** Help\
**Created:** [October 4, 2022, 11:46am UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451 "2022-10-04T11:46:29Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![David](https://avatars.discourse-cdn.com/v4/letter/d/aeb1de/32.png) [@David](https://fortran-lang.discourse.group/u/David)\
**Post date:** [October 4, 2022, 11:46am UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/1 "2022-10-04T11:46:29Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![interkosmos](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/interkosmos/32/296_2.png) [@interkosmos](https://fortran-lang.discourse.group/u/interkosmos)\
**Post date:** [October 4, 2022, 11:55am UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/2 "2022-10-04T11:55:57Z")

</div>

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`:

```auto
$ gfortran -o test test.f90 -ldummy

```

---

<div class="post-metadata">

**Author:** ![gnikit](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/gnikit/32/1213_2.png) [@gnikit](https://fortran-lang.discourse.group/u/gnikit)\
**Post date:** [October 4, 2022, 12:11pm UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/3 "2022-10-04T12:11:05Z")

</div>

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`

```auto
gfortran -Wall -o test test.f90 -L/path/to/lib -ldummy

```

---

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [October 4, 2022, 12:38pm UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/4 "2022-10-04T12:38:16Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![riadh](https://avatars.discourse-cdn.com/v4/letter/r/58f4c7/32.png) [@riadh](https://fortran-lang.discourse.group/u/riadh)\
**Post date:** [March 23, 2023, 1:17pm UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/5 "2023-03-23T13:17:27Z")

</div>

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:

```auto
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.

---

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [March 23, 2023, 1:58pm UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/6 "2023-03-23T13:58:50Z")

</div>

@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.

---

<div class="post-metadata">

**Author:** ![riadh](https://avatars.discourse-cdn.com/v4/letter/r/58f4c7/32.png) [@riadh](https://fortran-lang.discourse.group/u/riadh)\
**Post date:** [March 23, 2023, 6:03pm UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/7 "2023-03-23T18:03:52Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![Arjen](https://avatars.discourse-cdn.com/v4/letter/a/b9bd4f/32.png) [@Arjen](https://fortran-lang.discourse.group/u/Arjen)\
**Post date:** [March 23, 2023, 7:24pm UTC](https://fortran-lang.discourse.group/t/including-linux-so-files-in-fortran-programs/4451/8 "2023-03-23T19:24:23Z")

</div>

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.
