About the true nature of library files

[Grunde]

I'm working on a translation job from fortran to matlab, and I've been handed the source code of the fortran program. Not being proficient with fortran from before, I spent some days finding a decent compiler and learning the basics, and I ended up with a Silverfrost Plato. The source code is written in f77, and my version of plato (4.4) is supposed to handle it, so I have tried compiling it. It stops quite early though, telling me it isn't able to find some function or subroutine from a library file that came with the source code. Now I have tried linking these library files (.lib) in with the source code during compilation in many different ways, but with no luck at all. This hasn't actually disrupted my work so far, I've been able to isolate code not referring to the external libraries and compile it, but now I really need to compare my results in matlab with those in the fortran version, and so I've been frantically searching the web for information on libraries.

From what I've seen on this forum, my problem possibly lies in that whereas there are lib files in the source code folders, I can find no dll files. If I've understood it correctly, the lib files are just reference tools to dll files, used for compilation, and if this is indeed the case my problem will be a diplomatic one instead of a technical one. At first I thought they were just different extensions for the same type of file.

Still, I'm wondering if there is any way I can open them? read out what object files it is referencing to?

If anyone can tell me if I'm on the right path in terms of understanding library files as well, it would be super! =D

Double, double, toil and trouble
fire burn and cauldron bubble

 

[FJacq]

Sorry but I don't understand what you say.

A lib file has not to be used during the compilation phase but only just after (for building up the library itself) and later on during the link phase to produce the executable program.

A lib file is a static library (i.e. the oldest form of a library), whereas a dll is a dynamically linked library. The use of a lib file is much easier and much cleaner than the use of a dll file ! It has only one drawback today : it cannot be used as plugin (one of the reasons why dll have been invented).

If the libraries are already available, then you have just to link the object files and the library files together to produce the executable.

François Jacq

 

[Grunde]

I see, I'm really noobing off here. Somehow I haven't been able to both link the libraries and compile at the same time, and it feels like I have tried a lot of ways, but I will keep on trying. I managed to find the SLIM-part of plato though, so I've just made a list of the objects in the libraries and it seems all the called subroutines are there. I guess my problem is really just how to build the file correctly, then. Anyway, thanks a lot for the quick reply!

Double, double, toil and trouble
fire burn and cauldron bubble

 

[Grunde]

Can a library file link locally, though? one of the error messages I have got is referring to a local file path on one of the computers of the company that made the source code.

Double, double, toil and trouble
fire burn and cauldron bubble

 

[FJacq]

Please, publish the error messages you got (especially the first one) without trying to interpret or modifying them.

I don't use the silverfrost compilation system. So I don't know whether I will be able to help you. But I think that other participants to this forum will give you advices when reading these error messages.

François Jacq

 

[salgerman]

Hhhhmmm...I don't quite know what I am talking about here because I have the source code for everything I need, even so called libraries; so, at the risk of asking a stupid question, allow me to ask away:

Where do these lib files came from?
Have you inspected them?
Are they truly object files? or
Are they simply fortran sources (in ASCII) with *.lib extension?
If they are object files to be linked along, when and where were these lib files generated?
Are they compiler independent?
Are they platform independent?
Is there a chance to get the sources of those libraries in the first place?
It would be best to hunt down the sources of the libraries, too, re-compile them with the present compiler and in the current platform to ensure compatibility.

My 2 cetns.

 

[salgerman]

Oh, and I use the g95 compiler for a couple of reasons...one, it is free (gratis) and, two, because I some point I was supporting Solaris, Red Hat and Windows and with g95 available for all 3 platforms, I was able to use the exact same make files (same flags, etc) in all 3 platforms.

 

[Grunde]

@This error message I get when I try to run the program. I'm required to censor it, but +++ is the company name, and £££ is the name of the main part of the program. Here goes:

Runtime error from program:c:\documents and settings\gruwes\mine dokumenter\fortran\test£££2\£££\source\£££.exe
Run-time Error
*** Error 29, Call to missing routine : __OtsStringCompareEqlPadded at 0x0040a60d.


SETCAS - in file f:\users\+++\dv at line 4 [+003a] [recur= 1]

INIFRE - in file f:\users\+++\dv at line 31 [+0106]

£££ - in file £££.f at line 101 [+0049]


Now, the line 101 of the main routine is the first call to the libraries, more specifically INIFRE. Both INIFRE and SETCAS are supposedly contained in the libraries, whereas __OtsStringCompareEqlPadded is completely unknown to me, not listed anywhere.

@salgerman
If anyone sounds stupid here, it's me. I appreciate your efforts.
1. The lib files come from the company that made the code.
2. I have inspected them; they seem to be heavy collections of fortran routines and/or functions, therein all those that the program I'm working on calls.
3.I just managed to find out how to list the objects yesterday, and it seems they are object files. the libs are not readable by any program I've got (except as some sort of hexagonal number code). Truly I don't know how to differ between those two sorts.
4. The libs were generated in the mid 90s, I think, on a compaq visual fortran.
5. I have no idea if they are compiler independent
6. I have no idea if they are platform independent
7. I have gently requested the source code for them before without any luck. I will try again, and the chances are there but I not at this moment, without going into further details. I am aware that I may probably not be able to finish the job without looking at that source code.

I had a short look at g95, but being a total noob at fortran as well as linking and compiling manually (I'm used to matlab where I call functions from console, and Visual studio (c++) where I click "build"), I ended up going for plato, which seemed nice and neat, simple and with a couple of youtube tutorials. I am trying to get a hold of a compaq compiler of the same sort used in the original compilation here, but so far the progress is weak.


Double, double, toil and trouble
fire burn and cauldron bubble

 

[FJacq]

First of all, you get a RUNTIME error. So it does not seem to be connected to any static library (LINKTIME error in that case). It seems more related to a missing DLL... But I am not an expert of Windows which I don't use seriously anymore for years.

Let us add that __OtsStringCompareEqlPadded does not seem to be the name of a Fortran-77 procedure (in Fortran-77 conforming programs, names are limited to 6 characters and are in capital letters).

On the contrary, SETCAS and INIFRE look like typical Fortran77 procedure names.

How do you enter the list of libraries to link with in your environment ? I suggest also to modify the order, or to repeat from time to time these library : this may be important because linkers are often unable to recurse.

François Jacq

 

[Grunde]

Ah, ok. Missing dll, sounds like some deeper system-related stuff, and so I am guessing I should just stop what I'm currently doing and make some better use of my time until I manage to get my hands on the source code of the object files I need in the libraries.

I just tried linking them in different orders, with the same result.

Double, double, toil and trouble
fire burn and cauldron bubble

 

[salgerman]

Yeah, I am afraid that those lib files may not be re-usable with this new compiler of yours...What do you think about that, François ?

On the linux side, there is a tool that allows you to list what subroutines/functions have been included into a library, the command is called 'nm'...

I just googled nm and it seems like there are a couple of tools on the Windows side to do the same thing, like 'dumpbin.exe' and visual studio's 'depends'...

but I don't know those tools so I am not 100% sure if they do what they say...half the time, when a Linux user wonders for a Windows equivalent tool, the Windows users don't even understand the question in the first place...it is just too low level for them and their answers are not quite correct...going out on a tangent, here...let me get back...

I presume that your plato environment may have a tool of its own to show you the subs/funs inside a lib file...if not...

For lack of anything else, you can inspect the file yourself...because it is no longer in ASCII but instead it is now a mix of hexadecimal (not hexagonal, by the way) and ascii you need a hex editor to open this file and read, like these ones:

http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm

http://mh-nexus.de/en/hxd/

While most of the file may be hex, you will notice that the names of the subroutines/functions in the library are actually in plain ASCII...you should be able to read them on the right side panel of the hex editor.

Also, libraries are not INCLUDED in sources, nor compiled at compiled time...instead, they are linked at linking time and you typically need to add a '-L' flag (followed by the directory where the library is) in the link command...because you are using an environment like plato ( I know nothing about it, though) I presume that you do this in some GUI-based manner? Make sure you are doing this...specifying the directory for libraries, etc.

o.k., that's it for now.

 

[Grunde]

Yeah, Plato's got a SLIM program I can run from command, from which I can list all the content of the lib-file. I found it very late yesterday, and now I have a complete list with every object contained with corresponding sizes in terms of kB. I had already discovered that I could find some discernible text when I opened the lib files in notepad, Windows' most basic text editor, but there were some thousand lines of bull, and no search function, so I didn't want to go there.

You're right, I don't do the linking myself, no commandos are involved, I just press the "build" button, or ctrl+shift+B, and it will compile and link my files. I'm guessing the linking has actually been done, since the runtime error message is referring to lines in the code of subroutines found inside the libraries, won't this make sense?

Anyway, I've joined a silverfrost plato forum now, and it seems I have done everything right in terms of building the file and including the libraries, so the fault should lie in some code somewhere. Actually, I think I should try to do this on another computer as well, and maybe with another compiler. If I'm lucky it's just plato that can't handle this code.

Double, double, toil and trouble
fire burn and cauldron bubble

 

[xwb]

You could try the express version. Get visual basic or visual c++ express from the MS site. Install that then install Silverfrost Fortran Express.

Commands are the same, ctrl shift B to build etc. Visual studio can handle fairly large code bases.