- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
On Windows this is much easier and more reliable.
- Call GetModuleHandle naming your DLL - this returns a handle to the DLL that is loaded in your current executable
- Call GetProcAddress, supplying the handle and the name of the routine you want to call
- 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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page