How do I make installable, shared object library files?

[Vishnu]

I want to make <name>.so library files out of Fortran programs that can be installed in, say /usr/lib, linked as: -l<name>, and then have its MODULES used in a program, later.

How do I achieve this?

Say I have a file with one or more MODULEs. Do I compile it like this: ?

gfortran -O3 -shared -fPIC -o <name>.so <name>.f90

And then install the .so file in /usr/lib ? Is that all?

Also, what do I do with the <module_name>.mod files that are created?

[Wolfgang Kilian]

On 06.07.2018 11:40, Vishnu wrote:
> I want to make <name>.so library files out of Fortran programs that can be installed in, say /usr/lib, linked as: -l<name>, and then have its MODULES used in a program, later.
>
> How do I achieve this?
>
> Say I have a file with one or more MODULEs. Do I compile it like this: ?
>
> gfortran -O3 -shared -fPIC -o <name>.so <name>.f90
>
> And then install the .so file in /usr/lib ? Is that all?

This should work, and it is that simple. I don't remember the details,
but we're doing essentially this with our software, and it works.

(NB: I wouldn't install into /usr/lib but into /usr/local/lib, unless
the library is to become an integral part of the OS distribution.)

>
> Also, what do I do with the <module_name>.mod files that are created?
>

You need those files only if the code which uses the library needs
direct access to the internal definitions (types, module variables),
otherwise you don't install the .mod files.

If this is the case, you have to make the module files accessible to the
code that accesses the library, when that code is compiled. There is no
actual standard for that, unlike the include files of C libraries which
have their fixed place in a file system. I'd recommend to prepare a
project-specific subdirectory of /usr/local/lib. Note that unlike the
object code that is generated and installed as the .so library, the
format of the .mod files is specific for the compiler and for the
compiler version. So you may want to take this into account when
storing those files. The user of the library has to know that compiling
against the pre-compiled library works only for that compiler.

-- Wolfgang

[Vishnu]

> >
> > And then install the .so file in /usr/lib ? Is that all?
>

> (NB: I wouldn't install into /usr/lib but into /usr/local/lib, unless
> the library is to become an integral part of the OS distribution.)
>

The packaging standards of the distribution I'm doing this for require that library files go into /usr/lib, and modules into /usr/lib/<pkg_name>. I'm just following that.

> >
> > Also, what do I do with the <module_name>.mod files that are created?
> >
>
> You need those files only if the code which uses the library needs
> direct access to the internal definitions (types, module variables),
> otherwise you don't install the .mod files.
>
> If this is the case, you have to make the module files accessible to the
> code that accesses the library, when that code is compiled. There is no
> actual standard for that, unlike the include files of C libraries which
> have their fixed place in a file system. I'd recommend to prepare a
> project-specific subdirectory of /usr/local/lib. Note that unlike the
> object code that is generated and installed as the .so library, the
> format of the .mod files is specific for the compiler and for the
> compiler version. So you may want to take this into account when
> storing those files. The user of the library has to know that compiling
> against the pre-compiled library works only for that compiler.
>

I forgot to mention that I'm making a packaging script that a user may employ to 'compile' and install. So it is not a case where just binaries will be distributed.

So the .mod files will be compiled on every machine this is being installed to, and will be placed in /usr/lib/fmlib/.

In that case, do I need to supply any additional instructions for its usage (other than the link: -lfmlib) ? Will one also have to specify "-J /usr/lib/fmlib/" to point to the module directory?

[Wolfgang Kilian]

On 06.07.2018 13:35, Vishnu wrote:
>
>>>
>>> And then install the .so file in /usr/lib ? Is that all?
>>
>> (NB: I wouldn't install into /usr/lib but into /usr/local/lib, unless
>> the library is to become an integral part of the OS distribution.)
>>
>
> The packaging standards of the distribution I'm doing this for require that library files go into /usr/lib, and modules into /usr/lib/<pkg_name>. I'm just following that.

OK, that makes sense, so it is part of the OS, effectively.

>
>>>
>>> Also, what do I do with the <module_name>.mod files that are created?
>>>
>>
>> You need those files only if the code which uses the library needs
>> direct access to the internal definitions (types, module variables),
>> otherwise you don't install the .mod files.
>>
>> If this is the case, you have to make the module files accessible to the
>> code that accesses the library, when that code is compiled. There is no
>> actual standard for that, unlike the include files of C libraries which
>> have their fixed place in a file system. I'd recommend to prepare a
>> project-specific subdirectory of /usr/local/lib. Note that unlike the
>> object code that is generated and installed as the .so library, the
>> format of the .mod files is specific for the compiler and for the
>> compiler version. So you may want to take this into account when
>> storing those files. The user of the library has to know that compiling
>> against the pre-compiled library works only for that compiler.
>>
>
> I forgot to mention that I'm making a packaging script that a user may employ to 'compile' and install. So it is not a case where just binaries will be distributed.
>
> So the .mod files will be compiled on every machine this is being installed to, and will be placed in /usr/lib/fmlib/.

Again, that's consistent. I still would include a compiler-version
prefix in the .mod-file installation path, to make it clear to the user
that the pre-compiled modules will work only with that particular compiler.

On my distribution, there are several more recent versions of the
gfortran compiler available as packages, in addition to the version that
corresponds to the system gcc compiler. If the library has been
compiled with the system compiler, it will work with any of the other
compiler packages only to the extent that the .mod file format did not
change. (The gfortran experts may know more about that.) It certainly
won't work with a Fortran compiler from a different vendor, if the user
chooses to install and use that on the system.

> In that case, do I need to supply any additional instructions for its usage (other than the link: -lfmlib) ? Will one also have to specify "-J /usr/lib/fmlib/" to point to the module directory?

Yes, I don't think that gfortran has paths automatically included in the
module search path. It would work if there was a system-wide collection
of module search path that is to be preloaded by the compiler, so that
the package installation script could add the package to that one. I
don't know of such a feature, however.

-- Wolfgang

[Vishnu]

Okay, so I solved it all by placing:

- shared object files in /usr/lib
- .mod files in /usr/{lib/lib64}/gcc/x86_64-<name-linux>/<gcc_version>/finclude/

I can then get it to link to the library via flags.