Identify shared library from Fortran program

[Arnoux__Felix]

Dear FORTRAN experts,

I was recently promoted Code Custodian for a Fortran Linux program. Users would like to increase code flexibility, i.e. to use their own functions for some operations.

I suggested we could use shared libraries, which could be changed depending on the user needs, and compiled separately from the main code. However, we have then a problem of quality assurance. How can we trace in the code output files which shared library was used for a code execution ? I know that we could use an external script that would calculate the library's checksum (SHA or MD5, doesn't really matter), but it means an external script layer. Another possibility would be to rely on the library to print its own identity, but my users are sometimes a bit lazy, and the tend to keep existing code lines as long as they can (I do the same, therefore I can understand).

Is it possible from within a Fortran program to identify in a unique manner a shared library dynamically linked at the execution ? Using a checksum or any kind of function signature ? I have an Intel Composer XE 2015 compiler (and a strong headache).

Thank you for your help,

Felix

[jimdempseyatthecove]

>>Users would like to increase code flexibility, i.e. to use their own functions for some operations.

This implies that the Fortran code requires one or more shared libraries with specific names together with specific entry points with identical argument lists. The binding of the shared library occurs at runtime, and the selection of the same named library depends upon the library search order.

The easiest suggestion I have is to prohibit your users from having administrative privileges such that they can insert their library into one of the "global" library directories (e.g. /usr/lib). This would require them to use the environment variable LD_LIBRARY_PATH to add the path to the "user defined library". This also means that any default "user defined library" would have to be specified at login, then if desired, replaced by the user prior to use. Your Fortran program could then read LD_LIBRARY_PATH to locate the folder containing the library (since you know the name of the library).

Jim Dempsey

[Arnoux__Felix]

Thank you Jim,

You're right, library's name is well known, and my users cannot write to /usr/lib. However, you propose to parse all the locations contained in LD_LIBRARY_PATH looking for my library, which can be quite long, as some users have a very rich environment. What about the case when a user have two different libraries with same name in LD_LIBRARY_PATH ?

Let's say that I've found my library. Is there a way to identify it ? Checksum or anything ?

Thank you,

Felix

[jimdempseyatthecove · Accepted solution]

You can use FINDFILEQQ

USE IFPORT
CHARACTER(256) pathname
INTEGER(4) pathlen
pathlen = FINDFILEQQ("libYourLibHere.so", "LD_LIBRARY_PATH", pathname)
WRITE (*,*) pathname

If the pathname returned is the full path, then you should have

/home/UserNameHere/.../hisFolder

However, if the path returned is relative to ./ then you may need to use a system function to obtain the user name and/or path to . (GETCWD).

Once that is resolve, then you have the fully qualified file name.

Jim Dempsey

[Steven_L_Intel1]

This is so much easier on Windows....

Maybe you could do something with preprocessor macros such as __DATE__ and __TIME__ to "automatically" create version info that could then be inquired about through a call. You'd have to ensure that the source that used these macros always got recompiled.

[Arnoux__Felix]

Based on the instructions from Jim Dempsey, I managed to create a library, to use it and to indicate in my program's output file a path to the dynamically linked file.

Next step is to do the same for Window... I am not very familiar with Windows, can I use the same function (FINDFILEQQ) to look for a DLL ?

Many thanks,

Felix

[Steven_L_Intel1]

On Windows this is much easier and more reliable.

1. Call GetModuleHandle naming your DLL - this returns a handle to the DLL that is loaded in your current executable
2. Call GetProcAddress, supplying the handle and the name of the routine you want to call
3. Now you have the address of the routine in your DLL you want to call to get the info.

The GetProcessorInfo sample we provide (see https://software.intel.com/en-us/product-code-samples) demonstrates this.

If instead you want the full path to the DLL, call GetModuleFileName on the handle returned from GetModuleHandle.

Also on Windows you can define a "Version" resource that can be retrieved with an API call.