Fixing "unresolved external" errors
If you work in multi-DLL apps, chances are you'll eventually hit one or more "unresolved external" errors. For that to happen you need to have some code or data with the ,EXTERNAL attribute. The help has this to say about EXTERNAL:
The EXTERNAL attribute specifies the variable, FILE, QUEUE, GROUP, or CLASS on which it is placed is defined in an external library. Therefore, a variable, FILE, QUEUE, GROUP, or CLASS with the EXTERNAL attribute is declared and may be referenced in the Clarion code, but is not allocated memory--the memory for the variable, FILE, QUEUE, GROUP, or CLASS is allocated by the external library. This allows the Clarion program access to any variable, FILE, QUEUE, GROUP, or CLASS declared as public in external libraries.
An unresolved external error is a linker error - after compiling your source the linker needs to find your external data declarations in another library, usually a DLL But the linker doesn't directly associate your code with the DLL itself. Instead it links in a LIB file for that DLL; it's the LIB that contains information on where the variables are located in the DLL.
If you have unresolved external errors, and you don't know which LIB to include in your project, you can always do a text search of all the LIB files you have for any of the missing symbols. But if the symbols are in one of your own apps a search of all of the export (.EXP) files will probably give you a more readable result. (And if the symbol is in the EXP but not in the LIB you need to recompile that DLL!)
Two search utilities I use on a regular basis are Keystone Source Search (KSS) and Windows Grep. KSS is far and away the more powerful option for most Clarion source searching, but as I usually have a DOS window open somewhere I still use grep on a regular basis for quick searches.
Comments
Thanks Carl - great info as always!
For the inverse relationship the .LNK file is a text file that lists the LIB names (e.g. ClaRun.LIB) and other resources (e.g. ICO files) that the Linker has linked into your DLL or EXE, i.e. imported. It can be searched as text and opened in a text editor. It can be confusing that LNK is also the extension for Windows shortcuts so in Windows Explorer the “.LNK” extension is not shown and the file type is “Shortcut”. Right-click will not offer to let you treat it like a text file and open in Notepad. I usually add Notepad and UltraEdit to my SendTo folder so I can view any file as text.
The .MAP file contains detailed import information and is a text file that can be searched. All imports are listed one per line as LibName:$DataName or LibName:ProcedureName e.g. clarun:Cla$ACCEPTED. If you search MAPs for “DllName.LIB” you will not find it, you must search for “DllName:”. The best use is to find a list of APPs that import a function by searching the MAPs for "Dllname:Function".
I think of LIBs as mostly for simple Name exists checking, i.e. you imported MyProcedure() and if the Linker doesn’t find MyProcedure() then you get the unresolved external. The second LIB purpose is to give the Linker the exact case sensitive name because Windows is case sensitive. Getting the location (memory address) of the external thing is done by the Windows loader.
I suggest you open up a LIB, EXP, LNK and MAP file from some of your EXEs / DLLs in an editor and have a look around. Clarion 7+ changes the disk location of some of these files to the OBJ\build folder, the MAPs are in a MAP\build folder.