COBOL programming tools from NORCOM

     Products     Prices and Purchasing     Support     News     Partnerships     Home   Contact Us   Downloads

 

 

LINK: Creating Executables

So you've compiled your COBOL program and you have an object module that the compiler produced. Now what?

That object module is not in an executable form; it needs to be tweaked a bit so that Windows knows what to do with it when you launch it. That's where the linker comes in.

You don't see it in your source code, but all COBOL programs call subroutines in the operating system and in your compiler's runtime support modules. They may also call subroutines that you explicitly CALL in your code.

The linker ensures that all of these subroutine calls are resolved when the executable module is generated. For our purposes, you can assume that the linker does this by merging the object modules of called subroutines into your executable module.

Where does the linker obtain these additional object modules? From object libraries, of course.

Let's say that you have a main program A, that calls subroutines B and C (which you stored in your object library my.lib, of course), and that it uses GUI ScreenIO, so it also calls GS. Your LINK statement would look like this:

LINK a.obj /OUT:a.exe my.lib gs32.lib compiler.lib ...

This LINK statement says:

"Link my object module a.obj as an executable named a.exe, and search the libraries my.lib, gs32.lib, and compiler.lib (in order) for any subroutines it uses."

Unresolved Externals?

If a called entry point is not found in any of the object modules stored in any of the object libraries named in your link statement, the linker will return a message saying there is an "unresolved external". 

The most likely causes of an unresolved external are forgetting to include the library that contains the missing object module, or, if the module is one of yours, you forgot to include it in my.lib.

Efficiency Considerations

The linker will only include the modules from the object library that are needed by your executable, so it will be as small as possible.  

Suppose, on the other hand, you don't use object libraries and, instead, list the modules that the linker is supposed to bundle into your executable individually. The linker will incorporate all of the modules you named, regardless of whether they're used or not! This won't happen if you use an object library and let the linker determine which modules should be included in your executable.

Creating a DLL

If you want to create a dynamically loaded subroutine "a" (A.DLL), use:

-dll -out:a.dll -def:module-definition-file.DEF

instead of:

-out:a.exe

Note: The -DEF parameter is used when you need to have the linker create an import library, which allows your program to call entry points in the DLL in addition to the external name of the DLL.  

Other LINK Switches

There are a couple of other parameters you need to use with your linker. If you want Windows to treat your module as a native Windows executable, you need to include the switch:

-subsystem:windows,4.0

If you don't include this, you'll find that a Command window will open whenever you launch your application.

Related topics:

 

 



 

 

 

 

 

 

 

 



 

COBUG 
 Bringing COBOL
Together

 


© 2000-2019 Norcom, all rights reserved 

Contact Norcom